Re: Using Chunked encoding to send control messages to a client

Why can't the server just stop reading requests?  Then TCP will block the
sender automatically.

I don't think chunking alone will solve your problem.  You might be able to
get away with a MIME multipart response sent with chunked encoding.  The
issue that always gets raised when this kind of thing comes up is this:  an
HTTP proxy is allowed to buffer the response and remove the chunked
encoding, sending monolithic response to the client.  With the multipart
encoding, you could still pick apart the response, but now the timing would
be much different (you'd get all parts of the response at once).

That said, why would  a proxy ever want to do this buffering and
coalescing?  Most server vendors seem to abhor buffering arbitrarily large
quantities of data.  And, of course, there is a detrimental effect on
response time.  But that's the spec.  The HTTP spec even includes
pseudo-code for removing the chunked encoding and resending the body with
Content-Length.

     -Carl



James Lacey <jlacey@ftw.paging.mot.com> on 05/05/2000 06:46:33 AM

Please respond to James Lacey <jlacey@ftw.paging.mot.com>

To:   http-wg@hplb.hpl.hp.com
cc:
Subject:  Using Chunked encoding to send control messages to a client





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.

thx,

--jl

Received on Friday, 5 May 2000 08:50:33 UTC