W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 2000

Using Chunked encoding to send control messages to a client

From: James Lacey <jlacey@ftw.paging.mot.com>
Date: Fri, 5 May 2000 07:46:33 -0500 (CST)
Message-Id: <200005051246.HAA15091@iden012.ftw.paging.mot.com>
To: http-wg@hplb.hpl.hp.com

I'm using HTTP in an application as a transport for XML documents
that are 'POSTed' to a servlet for processing.

I am using persistent connections and I have a need to in some 
situations send a 'control message' back to a client indicating
that they have temporarily blocked from sending any more requests
to the server (say for example that the server has become very busy
and would like clients to stop sending requests until he can get
caught up).

I've thought about using chunked encoding to respond to a request
with a chunked message whose body indicates to the client he/she 
has been blocked. At a later time I can then send back another 
chunk indicating the client is no longer blocked, then send back
a chunk that has the response to the original request, and then
send back the zero chunk to indicate the end of the response.

I have some misgivings about this because I feel that it would
be using the chunked encoding for a purpose that it was not intended
for and the chunks should all collectively, once concatenated together,
make up the response to the original request.

Does anyone have any thoughts on this either way? Is it an OK thing
to do or is it a violation of the spirit of the protocol?

One problem I can see is that chunked responses are probably assembled
together on the client side at the session layer while the 'special'
control message needs to be understood at the application layer. It would
be bad for the session layer to have to know about application layer
control messages and somehow dispatch the event that one has been
received to the application lauyer.


Received on Friday, 5 May 2000 13:47:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:24 UTC