HYBI Working Group | G. Montenegro, Ed. |
Internet-Draft | Microsoft Corporation |
Intended status: Informational | March 14, 2011 |
Expires: September 15, 2011 |
HyBi WebSocket Requirements and Features
draft-ietf-hybi-websocket-requirements-02
This document states the requirements of the WebSocket Protocol. The goal of the document is to provide a stable base for protocol design and related discussion.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 15, 2011.
Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
HTTP [RFC2616] is a client/server protocol, where the HTTP servers store the data and provide it when it is requested by clients. When used to retrieve data from an HTTP server, the client sends HTTP requests to the server, and the server returns the requested data in HTTP responses. So the client has to poll the server continuously in order to receive new data.
Recently, techniques that enable bidirectional communication over HTTP have become more pervasive. Those techniques reduce the need to poll continuously the server thanks to the usage of HTTP hanging requests and multiple connections between the client and the server [I-D.ietf-hybi-design-space].
The goal of HyBi is to provide an efficient and clean two-way communication channel between client and server.
The communication channel will:
The goal of this work is to provide the set of requirements for the WebSocket Protocol.
In the following sections we list and analyse the requirements from the perspective of clients and servers.
This document uses the following HyBi-related terms:
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].
The following requirements for the WebSocket Protocol have been identified both in the HyBi wg input document [I-D.ietf-hybi-thewebsocketprotocol] and in the HyBi mailing list dicussion.
Reason: transfer data as message obviates the need for the receiver to parse/handle partial content.
Reason: This will allow dynamic messages to be constructed and sent without the need to buffer the entire message.
Reason: Some server developers would like to integrate WebSocket support into existing HTTP servers. In addition, the default HTTP and HTTPS ports are ofter favoured for traffic that has to go through a firewall, so service providers will likely want to be able to use WebSocket over ports 80 and 443, even when running a Web server on the same host. However there could be scenarios where it is not opportune or possible to setup a proxy on the same HTTP server.
Reason: Reusing existing well-debugged software decreases the number of implementation errors as well as the possibility to introduce security holes, and increases development speed, especially when the WebSocket server is implemented as modules that plug in to existing popular Web servers.
Reason: a clean shutdown signals that the other endpoint has definitely received all the messages sent prior to the close, so there is no protocol uncertainty about what has been processed and what can be retried on another connection.
Todo
Reason: This is in line with Req on HTTP compliance.
Reason: As the WebSocket protocol is expected to be often used in browsers, a careful design is necessary to mitigate the chances for hostile JavaScript to use WebSocket for a cross-protocol attack against vanilla HTTP resources or non-HTTP servers. More the design should prevent the possibility for cross-site XMLHttpRequest (using CORS or XDomainRequest) to be used for a cross-protocol attack against WebSocket resources, potentially violating integrity (though not confidentiality).
Subsequent discussion in the working group has determined consensus on the use of masking as one of the mechanisms to mitigate this concern.
This requirements document does not mandate any immediate IANA actions. However, such IANA considerations may arise from future HyBi specification documents which try to meet the requirements given here.
The initial requirements were created by Salvatore Loreto. Thanks to Greg Wilkins and Maciej Stachowiak for fulfilling previous editing duties.
[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. |
[I-D.ietf-hybi-thewebsocketprotocol] | Fette, I and A Melnikov, "The WebSocket protocol", Internet-Draft draft-ietf-hybi-thewebsocketprotocol-17, September 2011. |
[I-D.ietf-hybi-design-space] | Moffitt, J, Loreto, S, Saint-Andre, P and S Salsano, "Design Space for Bidirectional Protocols", Internet-Draft draft-ietf-hybi-design-space-00, June 2010. |