Internet DRAFT - draft-bt-http-broadcast
draft-bt-http-broadcast
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 ", ,
<http://www.rfc-editor.org/rfc/rfc2616.txt>.
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]
