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

From: James Lacey <[email-masked]>
Date: Fri, 5 May 2000 07:46:33 -0500 (CST)

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

---

From: [email-masked]
Date: Fri, 5 May 2000 09:34:42 -0600

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 <[email-masked]> on 05/05/2000 06:46:33 AM

Please respond to James Lacey <[email-masked]>

To:   [email-masked]
cc:
Subject:  Using Chunked encoding to send control messages to a client

thx,

--jl

---

From: Miles Sabin <[email-masked]>
Date: Fri, 5 May 2000 16:54:24 +0100

[email-masked] wrote,
> 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

That's one problem.

Another, which affects both chunked transfer encoding and the
multipart technique, is that a proxy is at liberty to set quite
a short idle-timeout (say 30 secs to a couple of minutes) to 
protect itself from hung origin servers and double-sided DOS 
attacks (malicious client on one side, malicious server on the
other).

Cheers,

Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
[email-masked]          http://www.cromwellmedia.com/