draft-lentczner-rhttp-00

draft-lentczner-rhttp-00
TOC
Internet Engineering Task Force
M. Lentczner
Internet-Draft
Linden Research, Inc.
Intended status: Informational
D. Preston
Expires: September 5, 2009
March 04, 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
The list of Internet-Draft Shadow Directories can be accessed at
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.
Table of Contents
1.
Introduction
1.1.
Requirements Language
2.
Protocol
2.1.
Overview
2.2.
Upgrade
2.3.
Example
3.
Considerations
3.1.
Host Header
3.2.
Connection
3.3.
Persistent Connections
3.4.
Fall Back
4.
Security Considerations
5.
IANA Considerations
6.
Normative References
Authors' Addresses
TOC
1.
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
TOC
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
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.
[RFC2119].
TOC
2.
Protocol
TOC
2.1.
Overview
A Reverse HTTP connection is established between hosts A and B as follows:
Host A establishes a TCP connection to host B.
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.
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.
TOC
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
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.
[RFC2616].
The protocol token used in the Upgrade header is:
PTTH/1.0
Section 10.1.2 of
HTTP
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.
[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.
TOC
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:
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
TOC
3.
Considerations
TOC
3.1.
Host Header
Section 14.23 of
HTTP
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.
[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.
TOC
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.
TOC
3.3.
Persistent Connections
Once established, the HTTP connection operating in reverse is just like any other
HTTP connection. In particular, the persistent 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.
TOC
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.
TOC
4.
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.
TOC
5.
IANA Considerations
This document asks IANA to register the token PTTH in the HTTP Upgrade Token
registry.
TOC
6. Normative References
[RFC2119]
Bradner, S.
, “
Key words for use in RFCs to Indicate Requirement Levels
,” BCP 14, RFC 2119, March 1997 (
TXT
HTML
XML
).
[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 (
TXT
PS
PDF
HTML
XML
).
TOC
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
Datatracker
draft-lentczner-rhttp-00
Expired Internet-Draft
(individual)
Document
Document type
Expired Internet-Draft
(individual)
Expired & archived
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is
not endorsed by the IETF
and has
no formal standing
in the
IETF standards process
Select version
00
Authors
Mark Lentczner
Donovan Preston
Email authors
RFC stream
(None)
Intended RFC status
(None)
Other formats
txt
html
xml
bibtex
bibxml
Report a datatracker bug
Show sidebar by default
Yes
No
Tab to show by default
Info
Contents
HTMLization configuration
HTMLize the plaintext
Plaintextify the HTML
Maximum font size
Page dependencies
Inline
Reference
Citation links
Go to reference section
Go to linked document