Network Working Group RS. Sankar, Ed. Internet-Draft BrioTribes Technologies (India) Pvt Ltd. Expires: September 14, 2013 March 13, 2013 Upgrading the 100-CONTINUE status for Broadcast in HTTP/1.1 Protocol draft-bt-http-broadcast-00 Abstract The Hypertext Transfer Protocol -- HTTP/1.1 in RFC 2616 uses the 100-Continue status message with Expect: Continue header to send request body at a later time to the origin server. This memo explains how to extend this status message to send multiple responses from the origin server to the client for an extended period of time. This achieves the essential function of broadcast from the origin server to the client, without the client waiting for a response to a request. Status of This Memo 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 14, 2013. Copyright Notice Copyright (c) 2013 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. Sankar Expires September 14, 2013 [Page 1] Internet-Draft Broadcast in HTTP/1.1 March 2013 1. Introduction The Hypertext Transfer Protocol -- HTTP/1.1 in RFC 2616 is essentially a request response protocol. A request has to be sent from the client to the origin server, for the server to send across any information to the client. In recent times HTTP/1.1 protocol is widely used to provide presentation logic for business applications. A number of business applications such as dashboard application requires a push functionality that pushes data from the origin server to the client without intervention from the client. In the standard approach called long-polling, the client starts a connection and waits for a response. The server responds when the data is available. Once a response is received, the client has to request again to receive the next message. Here, the server cannot send more than one response for the same request. This is better than polling, but it still requires the client to keep resending a request to receive a response. The best approach to broadcasting is for the client to initiate a request indicating that the connection is available to receive and process broadcast messages. The origin server and client maintain this connection. The server sends any broadcast message on this connection using 100-Continue status, when data is available. Once the timeout for the connection is reached, or the server decides no more broadcasts are possible on the connection, the server disconnects using the 200-OK message. The client can reestablish the connection if it requires to read more broadcast messages. In a broadcast, the ORIGIN SERVER is aware of when data is available to be sent and when no more broadcasts can be sent or when a broadcast connection has to be closed. For eg., when a client logs out of a session, the server is aware that the client is no more authorised to receive broadcasts or when a session times out, no more broadcast can be sent. Thus while the client initiates a connection, the server decides when to disconnect the connection. When the client initiates a broadcast request, if the server determines that the client cannot receive broadcast messages based on application logic, the server can send back an appropriate error message immediately such as 404-Not Present to prevent the client from receiving broadcast messages. 2. Extension to Extend 100:Continue status Sankar Expires September 14, 2013 [Page 2] Internet-Draft Broadcast in HTTP/1.1 March 2013 Broadcasting is a mechanism where an origin server can push data to a client without the client knowing when to expect data from the origin server. This upgrade proposes the following sequence to allow broadcast using HTTP/1.1 protocol: The client initiates a connection to the server with the below headers Expect: Broadcast Connection: Keep-Alive KeepAliveTimeout: time in ms The origin server recognizes the broadcast header. It interprets the header to indicate that the client can process broadcast data. The keepAliveTimeout is the time for which the connection will be open to process broadcast data. Once this initial connection is established by the client, the origin server will push data to the client using the 100-Continue messages. The data to be sent to the client is sent in the body of 100-Continue messages. The message is sent across with the following headers: Content-Length -- the length of content Content-Type -- the type of content The client uses the content-length to read the content of the data broadcast. More than one 100-Continue message can be sent before the 200-OK message is sent. For the current upgrade to work, both the client and the server MUST work with the upgraded 100-Continue status message. The client must process the 100-Continue status messages instead of ignoring them. Once the KeepAliveTimeout duration is reached, the server sends out the 200-OK message to close the connection. The KeepAliveTimeout can be an optional header. If the header is not present, then the connection is closed when the server determines it to be logically the end of broadcast. 3. Uses of HTTP Broadcast Sankar Expires September 14, 2013 [Page 3] Internet-Draft Broadcast in HTTP/1.1 March 2013 This upgrade can be used to send data in standard formats such as JSON or XML to be displayed via an AJAX call in an already loaded HTML page. Typical application includes dashboard kind of application, where data displayed needs to be updated only when they change or a multi- player game played online where one player action needs to be displayed in the screen of the other players. The intention of this upgrade is not to send multiple HTML pages on the same connection, but to send incremental data that needs to update only portion of the HTML page displayed. 4. References [httpproto] , "HTTP/1.1 Protocol RFC ", , . Author's Address Raji Sankar (editor) BrioTribes Technologies (India) Pvt Ltd. Phone: +91-9902530998 Email: raji.sankar@briotribes.com Sankar Expires September 14, 2013 [Page 4]