* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

hybi: Bidirectional communication for hypertext

The HyBi activity of the IETF coordinates work in the IETF related to several proposals for bidirectional, "long poll", and "reverse" HTTP: mechanisms where the connection is still initiated by the client but communication is initiated by the server.

Mailing List

Interested people should subscribe to the HyBi mailing list hybi at ietf.org.


o Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP: http://www.ietf.org/id/draft-loreto-http-bidirectional-01.txt

o Design Space for Bidirectional protocols: http://www.ietf.org/id/draft-loreto-design-space-bidirectional-00.txt

o The Web Socket protocol: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54

o Reverse HTTP: http://tools.ietf.org/html/draft-lentczner-rhttp-00

o Bidirectional Web Transfer Protocol -- BWTP/1.0: http://www.ietf.org/id/draft-wilkins-hybi-bwtp-00.txt

More Resources

o W3C The Web Sockets API: http://dev.w3.org/html5/websockets/

BOF at IETF-76 Hiroshima

The HyBi BOF will be held in Hiroshima with the goal to form a new Application area working group.

Preliminary time-slot:

TUESDAY, November 10, 2009
1300-1500 Afternoon Session I
Cattleya 1 APP hybi

Current Agenda:

 5 min   Agenda bashing                                Chairs
10 min   Design Space                                  Peter Saint-Andre
10 min   Charter Proposal Overview                     Chairs
         Technical Contribution so far:
10 min     Short Term and Requirements Input           Greg Wilkins
           Long Term and Requirements Input :
15 min       W3C / WebSocket Prospective               Michael Smith
15 min       WebSocket protocol in IETF                Lisa Dusseault
15 min       Other protocols and related use-cases     Greg Wilkins
30 min   Charter Proposal & Open Discussion            All
10 min   Calling the questions                         ADs

HyBi Working Group Charter Proposal

Current charter proposal (rev 2) under discussion, posted in http://www.ietf.org/mail-archive/web/hybi/current/msg00748.html. Comments are welcome on the hybi@ietf.org mailing list.

Proposed Charter for HyBi WG (rev.3)
Last Updated: 2009-10-29



Applications Area Director(s):
* Lisa Dusseault <lisa.dusseault@gmail.com>
* Alexey Melnikov <alexey.melnikov@isode.com>
Applications Area Advisor:
* Lisa Dusseault <lisa.dusseault@gmail.com>

Mailing Lists:
General Discussion: hybi@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/hybi
Archive: http://www.ietf.org/mail-archive/web/hybi/current/maillist.html

Description of Working Group:
HTTP has in the past been used as a request/response protocol most often,
leading to clients polling for new data or users hitting the refresh button
in their browsers.  Newer web applications are finding ways to push data
from the server to the client as soon as it is available, through a variety
of mechanisms.  The Hypertext-Bidirectional (HyBi) working group will seek
standardization of approaches that HTTP clients, servers, and intermediate
entities can use to communicate with one another in both directions.

Since any modification of the web infrastructure may take a good amount of
time to be deployed, outputs of the working group will include both short
and long term solutions.  The existing web being much more complicated than
it seems, the working group will prioritize the characterization of the
design space, including the web clients, intermediaries, firewalls, NATs,
web servers, etc. into which both solutions will need to be deployed.

For both short and long term work items, a general approach is preferred,
with abstract semantics that can apply to a large number of applications. 

The short term approach will be deployable on today's Internet, across
across HTTP proxies, servers and whichever current or historical web 
browsers the working group decides upon. Although wide browser support 
is a goal, lack of support on any single browser version will not be a 
sufficient cause to block consensus.  The short term approach may also 
define hints to allow HTTP-updated intermediaries and servers to optimize 

In the long term, new features will be required of clients, servers, or
intermediaries allowing a more scalable and robust end-to-end experience.

Although multiple protocols exist as starting points for both the short and
long term, backward compatibility with these protocols is not a requirement.
In particular, the working group will liaison with the W3C WebApps working group 
around the WebSockets protocol and the requirements to support the WebSocket API;
if agreed by both parties, the HyBi working group may take on prime responsibility
on the specification of the WebSockets protocol.

Wide browser support is a goal for long term solution, however the solution 
should also be suitable for clients other than Web Browser. 
The Working Group will work to standardize a generic solution that can work 
efficiently  in all the environments and elements of the web infrastructure 
(e.g. web browser, generic HTTP client, HTTP server and HTTP-aware intermediaries 
like proxies, load balancers, caches, etc.) and it is not specific for just one.

The Working Group should consider:
* Implementer experience
* Impact on existing implementations and deployments
* Ability to achieve broad implementation
* Ability to address broader use cases than may be contemplated by the
original authors

The Working Group will produce one or more documents suitable for
consideration as Proposed Standard that will:
* Define requirements for short- and long-term solutions, including
characterization of the design space
* Define a short-term solution for the bi-directional web, deployable on
today's Internet
* Define a long-term solution for the bi-directional web, which will likely
require modifications to the web infrastructure

Goals and Milestones:
Mar-2010:  WGLC on the Design Space characterization (Informational)
May-2010:  WGLC on Requirements document on Short term solution
Jul-2010:  WGLC on Requirements document on Long term solution 
Nov-2010:  Requirements to IESG
Mar-2011:  WGLC on Short term solution improvements
Nov-2011:  WGLC on Long term solution protocol

- Old stuff -

Use Cases

  • Connecting a rich user interface (either in browser or stand alone program) to a server:
    • IM
    • Controlling model trains
    • Collaborative editing as seen in tools like Google Apps
    • Multiplayer games
    • Monitor services, e.g. a wifi router's status page, showing up-to-date information about signal:noise ratios, etc.
  • Streaming data from device:
    • stock prices
    • industrial data loggers (temperature sensors etc. flow rates)
  • Gateway to mobile HTTP server (with unknown IP or firewall prohibiting inbound connections).
  • Tunnelling other protocols through restrictive firewalls (eg XMPP, VoIP)

Current Techniques

Long Polling

Long polling is an form of HTTP polling in which the server may delay response until data is available. Once data is available, a complete HTTP response is sent to the client and the client initiates another long-poll.



  • Browser connection limit
  • Latency
    • server may only respond to pending requests, so there is a period after sending a long poll response and before the next long poll is received that the server cannot immediately send an event.
    • responses cannot be pipelined
    • the latency issues could be addressed if multiple long poll requests are pipelined on a single connection. However lack of client control of pipelining make this currently not a practical option.
  • Clients or proxies may pipeline normal requests behind a long poll request, causing them to be delayed until the long poll is serviced.
  • cross-origin limitations with XHR technique or lack of failure notifications with script tag technique

HTTP Streaming

A push technique in which the server incrementally writes to a long-lived response.


  • Responses may be sent immediately without waiting for client.
  • Responses may be pipelined.


  • Subject to buffering by some intermediaries. (Note: most implementations of HTTP streaming also have the capability to fall back to long polling.)
  • No requirement for a client to process response data until the end of the response has been received. Some implementations have needed to send white space to cause a buffer overflow to trigger evaluation of a partially received response.
  • No streaming upstream (browser -> server). This means that there are no data packets available to piggyback TCP acknowledgements on, thus dedicated ack packets must be sent, which can negate some of the advantages over long polling.

Related Issues

Raising Two connection limit

Current browsers are circumventing the issues generated by the 2 connection limit by increasing the limit to 6 or 8. This is against the recommendation of RFC2616 8.1.4 which states:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy

There are concerns that increasing the limit:

  • Only defers rather than resolve the issues associated with a connection limit. Rich applications may easily consume 8, 16 or more connection to the server.
  • Circumvents the flow and congestion control mechanisms built into TCP/IP. Potentially this places user-agents that respect the 2 connection recommendation at a disadvantage on a congested network.
  • Increases the probability of normal requests pipelining behind long polls

Firewalls & Transparent Proxies

"The problem of firewalls and transparent proxies in the existing infrastructure" is an important topic to address and deserves analysis _independent_ of API and low-level protocol.

  • Corporate firewalls sometimes block all TCP connections, except for port 80 and 443.
  • Some firewalls sniff HTTP URLs, HTTP headers and even the content (e.g. checking for viruses), and block based on those.
  • Transparent HTTP proxies and proxy-caches on port 80 are common both in corporate settings and home internet connections. Maybe not the majority of connections (I have no figures), but enough to matter.
  • Explicit HTTP proxies which pass HTTP CONNECT requests often limit that to port 443.
  • It would be surprising if any widely deployed HTTP proxies, explicit or transparent, currently work with HTTP UPGRADE.
  • Common commet protocols have determined that long polling is more reliable than slow-streaming-GET, because some HTTP proxies don't forward any of the response until they have received the whole response.
  • Any apparently-binary protocol which is opaque to intermediate firewalls/proxies is likely to be blocked at many sites who are currently able to use protocols which tunnel over HTTP. I suspect blanket blocking is more likely when there's no distinguishing metadata in the protocol for a firewall to match on.



Candidates Requirements

The following "requirements" are distilled from the mailing list from what people have described as good protocol attributes. There has been no process applied to select a consensus set of requirements.

HTTP Style framing

HTTP style framing refers to:

  • textual name value headers associated with each message.
  • standardized headers for determining content type, encodings and transport details
  • arbitrary binary message bodies with either predetermined length or chunked.

There is a wealth of experience with generating and parsing HTTP style protocols. The extensibility and flexibility supported has proved useful in allowing HTTP to adapt to evolving requirements.


A connection can be used by either end to asynchronously initiate messaging.


Multiple channels allows multiplexed connection sharing so that a single socket can be easily shared by multiple widgets, frames, tabs and/or windows (using browser examples).


Interleaving is important to support large messages (like video files, say) which don't block small messages. Without interleaving we'd force each application developer to produce their own splitting and sliding window protocol whenever they _might_ have a large message, which is silly when we can do it in the protocol nearly for free.

Multiple Request paradigms

Currently HTTP supports request/response style messaging. Additional semantics of request/multi-response and request/no-response are desirable to improve efficiency and to better match some applications.

Capability negotiation

The capabilities of servers, browsers and network intermediaries may vary with regards to their support for current and future protocols and standards. The ability to negotiate the maximum capabilities of the entire communication chain is important so that capabilities will not be assumed and interoperability with older equipment is possible.

Fallback capabilities

If capabilities are not present on the network, then fallback(s) should be available to achieve similar communication semantics over HTTP.


Web Socket


  • API designed for HTML5
  • bidirectional over single socket
  • Dedicated UTF-8 datagram support
  • Not "HTTP Style" framing.
  • No per datagram meta data
  • Not multiple interleaved channels over single socket
  • Dedicated UTF-8 datagram support lacks support for transport encodings.
  • Limited packet-type identifier which is not user-extensible.
  • Does not directly support request/response, request/multi-response or request/no-response. Application must coordinate datagrams.
  • Associated URL is per connection.

Reverse HTTP


  • "HTTP Style" framing and headers
  • supports request/response
  • Associated URL per request
  • Not bidirectional over single socket
  • Does not support request/multi-response or request/no-response


RFC3080, RFC3081, http://beepcore.org/

  • Existing RFC and implementation
  • "HTTP Style" framing and headers
  • bidirectional over single socket
  • multiple interleaved channels over single socket
  • supports request/response, request/multi-response
  • Channel setup needs an request/response cycle (and extensions for auto channel creation constrain message ordering)
  • Control messages in XML
  • Does not support request/no-response

Asynchronous HTTP

Jamie Lokier described a suggested extension to HTTP with:

  • HTTP or simplified-HTTP message headers and body.
  • Bidirectional - either side can send requests and responses.
  • Channel id attached to each message.
  • Chunked encoding, with channel id attached to each chunk.
  • Per channel flow control exactly like BEEP over TCP profile.
  • Request/response id attached to each message.
  • Request/response id matches responses out of order to requests.
  • Pure messages with no response allowed, using "no-response" r/r id.
  • All the above features are optional.
  • As features are not supported, it degrades gracefully to HTTP pipelining then to HTTP persistent connections.
  • "HTTP Style" framing and headers
  • bidirectional over single socket
  • multiple interleaved channels over single socket
  • supports request/response, request/multi-response * request/no-response
  • Associated URL per request
  • No formal proposal ?

HTTP Upgrade

A sentiment has been expressed that perhaps the HyBi group should not try to pick a specific "winner" with regards to selecting a single bidirectional protocol. Instead the group could examine issues that exist for using the HTTP upgrade mechanism to upgrade to an arbitrary bidirectional protocol and produce recommendations for HTTP clients, servers, proxies and gateways that would allow various protocols to be used, to evolved and to compete for wide support.