Internet Engineering Task Force                             M. Lentczner
Internet-Draft                                     Linden Research, Inc.
Intended status: Informational                                D. Preston
Expires: September 5, 2009                                 March 4, 2009


                              Reverse HTTP
                        draft-lentczner-rhttp-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 5, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This memo explains a method for making HTTP requests to a host that
   cannot be contacted directly.  Typically, such a host is behind a
   firewall and/or a network address translation system.



Lentczner & Preston     Expires September 5, 2009               [Page 1]

 
Internet-Draft                Reverse HTTP                    March 2009


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.3.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Considerations  . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Host Header . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.2.  Connection  . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.3.  Persistent Connections  . . . . . . . . . . . . . . . . . . 5
     3.4.  Fall Back . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7


































Lentczner & Preston     Expires September 5, 2009               [Page 2]

 
Internet-Draft                Reverse HTTP                    March 2009


.  Introduction

   HTTP has become widely used as an application layer transport.
   Systems such as XML-RPC and SOAP, as well as numerous "web APIs" such
   as the Flickr API, all use HTTP as a method for having a client make
   requests of a server.

   The design of HTTP is such that the entity that initiates the TCP
   connection over which HTTP flows is also the entity that issues the
   request.  When building applications over HTTP where the hosts
   involved can both function as TCP servers, this is no problem: When
   either host wishes to invoke an function on the other, it can
   initiate a TCP connection to the other, and acting as the client in
   the HTTP protocol, issue the request.

   In many HTTP based applications, one of the hosts cannot function as
   an HTTP server.  Typically, the host may be behind a firewall, or not
   have a publicly routable IP address.  In this case, application layer
   interfaces can no longer be symmetric: If a host needs to invoke a
   function on a host that cannot function as an HTTP server, than that
   function cannot be easily layered on top of HTTP.  Typical designs to
   work around this constraint involve different encodings and semantics
   for requests from the server host to the non-server host, and the use
   of the long-poll technique.

   Reverse HTTP is designed to enable the application layer encoding and
   semantics to be built upon HTTP uniformly for requests in either
   direction between a non-server host and server host.  Since the non-
   server host cannot be contacted directly, the non-server host still
   needs to establish the TCP connection, but once the Reverse HTTP
   protocol is negotiated, the full HTTP protocol is used in the reverse
   of the normal direction: from the server to the client

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


.  Protocol

2.1.  Overview

   A Reverse HTTP connection is established between hosts A and B as
   follows:





Lentczner & Preston     Expires September 5, 2009               [Page 3]

 
Internet-Draft                Reverse HTTP                    March 2009


   1.  Host A establishes a TCP connection to host B.

   2.  Host A makes an HTTP request to host B. This request indicates
       A's willingness to engage in Reverse HTTP, and supplies any
       identification, authentication and authorization needed by B. The
       request is signaled by the Upgrade header in the request.
       Typically, the request is also indicated by a particular URL, and
       the other information encoded in the URL, body, or cookies, but
       applications are free to use any methods they wish for these
       purposes.

   3.  Host B signals its agreement to enter into Reverse HTTP by use of
       a 101 status code and the Upgrade header in its response.  At the
       conclusion of this response, the original HTTP connection is
       considered abandoned, and a new HTTP connection is established
       where host B is in the role of client and host A in the role of
       server.  From then on, request messages can be sent from B, with
       responses from A.

2.2.  Upgrade

   The switch to Reverse HTTP is signaled via HTTP's Upgrade header and
   upgrade mechanism, as described in sections 14.42 and 10.1.2. of
   RFC2616 [RFC2616].

   The protocol token used in the Upgrade header is:
   PTTH/1.0

   Section 10.1.2 of HTTP [RFC2616] defines the precise point of the
   protocol switch: Directly after the empty line of the response
   message containing the Upgrade header.  At this point, the new
   connection proceeds with the full HTTP protocol, as if the TCP
   connection had just been established, but with the parties in
   reverse: the original server acting as the HTTP client, sending
   request messages, and the original client acting as the HTTP server,
   sending response messages.

2.3.  Example

   In this example, host A will contact host B, and indicate it's
   willingness to enter into Reverse HTTP, and then process request
   messages from B:









Lentczner & Preston     Expires September 5, 2009               [Page 4]

 
Internet-Draft                Reverse HTTP                    March 2009


   A --> B: POST /message-queue?id=iamsam HTTP/1.1
            Host: b.example.com
            Upgrade: PTTH/1.0
            Connection: Upgrade

   A <-- B: HTTP/1.1 101 Switching Protocols
            Upgrade: PTTH/1.0
            Connection: Upgrade

   A <-- B: GET /status HTTP/1.1
            Host:

   A --> B: HTTP/1.1 200 OK
            Content-type: text/plain
            Content-Length: 4

            Good


.  Considerations

3.1.  Host Header

   Section 14.23 of HTTP [RFC2616] requires that all HTTP/1.1 requests
   have a Host header.  However, if the URI requested doesn't include an
   internet host, then the Host field is empty.  In the case of Reverse
   HTTP, the URI requested refers to a resource on Host A, which does
   not have an host name or IP accessible to Host B. As such, the Host
   field in request messages from B SHOULD contain an empty Host field.

3.2.  Connection

   The Upgrade mechanism is defined to be a hop-by-hop level in HTTP.
   As such, the Upgrade header is required to be listed in a Connection
   header in both the request message and the response message.  Reverse
   HTTP, however, is establishing an end-to-end establishment of an HTTP
   connection in the reverse direction.  Thus, Reverse HTTP upgrade can
   only be used with a proxy if the proxy is willing to establish
   Reverse HTTP on the next hop, or the CONNECT verb is used with the
   proxy to first establish a tunnel.  Where Reverse HTTP is used over
   HTTPS connections, there is no problem, even in the face of proxies,
   because those proxies establish an end-to-end tunnel that constitutes
   a single HTTP hop.

3.3.  Persistent Connections

   Once established, the HTTP connection operating in reverse is just
   like any other HTTP connection.  In particular, the persistent



Lentczner & Preston     Expires September 5, 2009               [Page 5]

 
Internet-Draft                Reverse HTTP                    March 2009


   connection mechanisms of both HTTP 1.0 and 1.1 are available.  In
   this way, a host can establish a bi-directional HTTP based
   communication to another host using two TCP connections: One running
   a persistent HTTP connection to the remote host, and another, after
   negotiating Reverse HTTP, running a persistent HTTP connection from
   the remote host back to itself.

3.4.  Fall Back

   Applications can be developed where not all hosts have to understand
   Reverse HTTP.  If the non-server host doesn't understand Reverse
   HTTP, then the server will not see an Upgrade token of PTTH/1.0 and
   so will know to fall back to some other application method of routing
   requests to the non-server host.  If the server doesn't understand
   Reverse HTTP, then it will respond to the HTTP request, ignoring the
   Upgrade token.  In such cases, the non-server host will see a
   response that corresponds to the fall back method.

   The actual method of fall back is beyond the scope of this memo.  The
   authors have experimented with various forms including JSON and XML
   encoding of application level requests, and more generic encoding of
   HTTP messages into HTTP message bodies.  In general, existing
   applications can migrate to Reverse HTTP and keep their existing
   techniques as fall back.


.  Security Considerations

   Reverse HTTP introduces no new security concerns beyond those known
   with HTTP.  However, as it applies HTTP in a novel way, the common
   security concerns need to be applied to the parties in reverse.  In
   particular, client software that initiates Reverse HTTP must realize
   that it will act as a server once the upgrade is complete, and so
   prepare it self for almost all the same issues any HTTP server must
   be concerned with.  The security concerns can be lessened somewhat in
   that the client need not be prepared for arbitrary requests from the
   Internet.  HTTP requests can only come from the host the client
   chooses to connect and establish Reverse HTTP to.  Standard
   precautions, such as negotiating TLS or using HTTPS, should be use so
   that the client can rule out man-in-the-middle and impersonation
   attacks.


.  IANA Considerations

   This document asks IANA to register the token PTTH in the HTTP
   Upgrade Token registry.




Lentczner & Preston     Expires September 5, 2009               [Page 6]

 
Internet-Draft                Reverse HTTP                    March 2009


.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.


Authors' Addresses

   Mark Lentczner
   Linden Research, Inc.
   945 Battery St.
   San Francisco, CA  94111
   US

   Phone: +1 415 243 9000
   Email: zero@lindenlab.com


   Donovan Preston

   Email: dsposx@mac.com


























Lentczner & Preston     Expires September 5, 2009               [Page 7]