User:Ryan94114/Enter your new article name here

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Reverse Http is a method for allowing world wide web servers to update clients with new information.

As it was designed, the http protocol describes the way in which a client sends an http request to a server, which in turn provides an http response. Most often requests take the following form:

  • Get: The most common kind of client request provides a URI. The server responds with a status indicator along with an html page.
  • Post: The client
  • Put: This request

Reverse HTTP is an experimental protocol which takes advantage of the HTTP/1.1 Upgrade: header to turn one HTTP socket around. When a client makes a request to a server with the Upgrade: PTTH/0.9 header, the server may respond with an Upgrade: PTTH/1.0 header, after which point the server starts using the socket as a client, and the client starts using the socket as a server. There is also a COMET-style protocol which will work with HTTP/0.9 or 1.1 clients that do not know how to perform this upgrade.

March 2009: Zero and Donovan submitted an Internet-Draft formally describing this.

Below is an example transcript using Reverse HTTP. Lines on the left are traffic from the client to the server. Lines on the right are traffic from the server to client. Lines with a red background are HTTP requests. Lines with a green background are HTTP responses.

The transcript was created by sniffing the traffic from running this script [1].

client -> server server -> client
Host: localhost:9999
Accept-Encoding: identity
Upgrade: PTTH/0.9
HTTP/1.1 101 Switching Protocols
Content-type: text/plain
Upgrade: PTTH/0.9
Date: Tue, 13 May 2008 20:14:45 GMT
Content-Length: 0
GET / HTTP/1.1
Accept-Encoding: identity
accept: text/plain;q=1,*/*;q=0
HTTP/1.1 200 OK
Content-type: text/plain
Date: Tue, 13 May 2008 20:14:45 GMT
Content-Length: 15
!dlrow ,olleH

COMET Fallback[edit]

If the client or server is incapable of upgrading from HTTP, a COMET-style protocol can be used instead. The server can maintain an event queue and require that the client repeatedly POST to the queue's resource to receive events. Below is a protocol trace using JSON as the protocol encoding.

Host: localhost:9999
Accept-Encoding: identity
HTTP/1.1 200 OK
Content-type: application/json
Date: Tue, 13 May 2008 20:14:45 GMT
Content-Length: 210
{'message-id': 'xxx', 'method': 'GET', 'request-uri': '/', 'http-version': 'PTTH/0.9', 'headers': [['Host', ''], ['Accept-Encoding', 'identity'], ['Accept','text/plain;q=1,*/*;q=0']], 'body': }
Host: localhost:9999
Accept-Encoding: identity
Content-type: application/json
Content-length: 193
{'message-id': 'xxx', 'http-version': 'PTTH/0.9', 'status': 200, 'reason': 'OK', 'headers': [['Content-type', 'text/plain'], ['Date', 'Tue, 13 May 2008 20:14:45 GMT']], 'body': '!dlrow ,olleH'}
HTTP/1.1 200 OK
Content-type: application/json
Date: Tue, 13 May 2008 20:14:45 GMT
Content-Length: 2

A response of {} from the server means no server-side event occurred within some timeout, and that the client should poll again if it wants to keep receiving events.

Another idea is to use text/plain encoding instead of JSON, and just have the actual text of the HTTP request in the response, and the text of the response in the next request. In this case, the message-id would be relayed in a header instead of in the body. Perhaps the message id should always be relayed in a header and never in the body?

form of "get", "put", "post", or "delete",

, which then responds back to the client with a response. The server typically waits for incoming requests from clients, producing a response keyed a URI and a "get", "put", "post", or "delete".

the server stands by waiting for incoming clients to make a request.

two-sided communication between the server and client, a process which otherwise relies upon ad-hoc approaches such as those used by Ajax.

communication in the http protocol to go in two directions rather than one.

the one-sided nature of the World Wide Web's http protocol without resorting to side-communication by programs such as AJAX. By default, the http protocol assigns one side to be the "client" and the other the "server". The server is typically available to handle incoming requests coming from a client. Unfortunately, there are times when a server needs to update information 


   * Home
   * Demo
   * Download
   * Draft Specs

ReverseHttp Demo service: Offline

I have taken the free reversehttp service offline for the foreseeable future, because the traffic bill has been getting too high. If anyone would like to sponsor or host the publicly-available service, or would like advice on configuring a service instance of their own for their own use, please get in touch.

Please see here for more information. Introduction

Polling for updates is bad. We've known this for about as long as computers have existed. So why are so many web-based services (SUP, RSS and Atom feeds, Twitter, etc.) based around polling?

The answer lies, first and foremost, in the asymmetry of HTTP. The web is split into two pieces: programs that make requests, and programs that handle them. It's very rare to see a single program behaving as both a client and a server.

To fix the asymmetry, we need to be able to act as if being able to respond to HTTP requests was within easy reach of every program, so that we can notify interested parties of changes by simply sending an HTTP request to them. This is the core idea of web hooks.

We need to push the messy business of dealing with long-polling away from the core and toward the edge of the network, where it should be.

We need to let programs dynamically claim a piece of URL space using a plain old HTTP client and handle requests sent to URLs in that space using that same HTTP client.

Once that's done suddenly asynchronous notification of events is within reach of any program that has access to an HTTP client library, and protocols and services layered on top of HTTP no longer have to contort themselves to deal with the asymmetry of HTTP. They can assume that all the world's a server, and simply push and pull content to and from whereever they please. The Solution

Tunnel HTTP over HTTP, in a structured, controllable, securable way. Let programs claim part of URL space, and serve HTTP, all by using an ordinary HTTP client library.

   * Read the draft specifications.
   * Check out the implementation.
   * Try the demos.

Even programs running in very restrictive environments, such as Javascript programs in the browser, can take advantage of a ReverseHttp service. The current implementation provides small, simple libraries for Python, Java and in-browser Javascript. Why hasn't this been done before?

This isn't a completely new idea, it seems, though it doesn't seem to be widely used — yet.

At around the same time as I was writing ReverseHttp (i.e. May 2008), Donovan Preston at Second Life was writing up his take on the same idea, which he also called Reverse HTTP (a.k.a "PTTH"). His idea is to use the HTTP 1.1 Upgrade header to switch the direction of the protocol, which works well for non-browser environments. He also has a Comet-based solution very similar to mine, except that it uses JSON objects for describing the HTTP requests and responses where mine uses the actual HTTP message formats. Donovan Preston writes more about the Second Life variant here, and has, with Mark Lentczner, produced an Internet-Draft for the Upgrade-header based protocol. Download and links

A reverse proxy is either a proxy server that is installed on a server network or on network equipment. Typically, reverse proxies are used in front of Web servers. All connections coming from the Internet addressed to one of the Web servers are routed through the proxy server, which may either deal with the request itself or pass the request wholly or partially to the main web servers.

A reverse proxy dispatches in-bound network traffic to a set of servers, presenting a single interface to the caller. For example, a reverse proxy could be used for load balancing a cluster of web servers. In contrast, a forward proxy acts as a proxy for out-bound traffic. For example, an ISP may use a proxy to forward HTTP traffic from its clients to external web servers on the Internet; it may also cache the results to improve performance.

There are several reasons for installing reverse proxy servers:

  • Security: reverse proxies provide an additional layer of defense by masquerading the web server behind the proxy. Reverse proxies can also provide Application firewall features, to protect against common web-based attacks.
  • Encryption / SSL acceleration: when secure websites are created, the SSL encryption is sometimes not done by the Web server itself, but by a reverse proxy that is equipped with SSL acceleration hardware or software.
  • Load distribution: the reverse proxy can distribute the load to several servers, each server serving its own application area. In the case of reverse proxying in the neighborhood of Web servers, the reverse proxy may have to rewrite the URLs in each webpage (translation from externally known URLs to the internal locations).
  • Caching: A reverse proxy can offload the Web servers by caching static content, such as images, as well as dynamic content, such as a HTML-page rendered by a content management system. Proxy caches of this sort can often satisfy a considerable amount of website requests, greatly reducing the load on the central web server; another term is Web accelerator. This technique is also used for the Wikipedia servers.
  • Compression: the proxy server can optimize and compress the content to speed up the load time.
  • Spoon feeding: a dynamically generated page can be produced all at once and served to the reverse-proxy, which can then return it to the client a little bit at a time. The program that generates the page is not forced to remain open and tying up server resources during the possibly extended time the client requires to complete the transfer.

See also[edit]

  • Proxy server
  • Apache HTTP Server may be extended with mod_proxy to be used as a reverse proxy; a caching reverse proxy server may be configured using the mod_cache module in conjunction with mod_proxy.[1]
  • Apache Traffic Server - An open source, high-performance routing and caching server
  • CACHEbox is a high performance HTTP/HTTPS/FTP caching proxy appliance supporting reverse as well as forward deployment modes.
  • Internet Information Services 7.0 with URL Rewrite v2 and Application Request Routing can act as Reverse Proxy.[2]
  • Lighttpd can be used as a reverse proxy with load balancing capabilities.
  • LiteSpeed Web Server can be used as a transparent reverse proxy server running in front of any web server or application server that supports HTTP protocol.
  • Microsoft ISA Server - A commercial proxy, firewall and caching solution by Microsoft.
  • Nginx - Web and Reverse proxy server.
  • Novell Access Manager is a commercial security solution which includes a reverse proxy, a policy based access manager and SSL VPN. All components use a LDAP like directory or federation with Liberty and others.
  • Perlbal is a Perl-based reverse proxy load balancer and web server.
  • Pound, a lightweight open source reverse proxy.
  • Squid is a proxy server that may be installed in a reverse proxy configuration.
  • Stunnel can be used as a local SSL reverse proxy.
  • Sun Java System Web Server includes reverse proxy module with load balancing capabilities.
  • Varnish is a performance-focused open source reverse proxy. It has a policy configuration language to allow extension. It features ESI, SaintMode, DNS director and native support for In-line C.
  • WinGate supports reverse-proxying with SSL, authentication, and multiple virtual hosts.
  • Zeus is a product that can function as both a forward and reverse proxy, as well as content load balancer.
  • McAfee Web Gateway is a product that can act as a reverse proxy. At the same time provide SSL decryption, caching, AV, Anti-Spam and other threat detection techniques.


     Instructions for downloading the implementation are here
     There's lots of thinking from others along the same lines:


External links[edit]

Category:Articles created via the Article Wizard

[Docs] [txt|pdf|html] [Email] [Nits]

Versions: 00

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


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-
  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 (
  Please review these documents carefully, as they describe your rights
  and restrictions with respect to this document.


  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

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

1.1. Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  document are to be interpreted as described in RFC 2119 [RFC2119].

2. Protocol

2.1. Overview

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

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
  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:
  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
           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
  A --> B: HTTP/1.1 200 OK
           Content-type: text/plain
           Content-Length: 4

3. 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.

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

5. 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

6. 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
  Phone: +1 415 243 9000              

  Donovan Preston

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

Html markup produced by rfcmarkup 1.90, available from