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

Also, I don't think chunked encoding, nor any content send after a
response/request is for control. Only the request-/response-lines
and -headers are intend for control. Maybe a better way for this, since it
is when the client sends data, to send responses indicating to
continue/pause sending.
You could use 100 to let the client send again and 124 (mentioned a number)
to let the client pause sending.

However some (older???) proxy may interpet 1xx responses as final, others
maybe not even send them to the client, but instead discard it (MAYBE). But
maybe this is a better solution after all......

Joris.

-----Original Message-----
From: Miles Sabin [mailto:msabin@cromwellmedia.co.uk]
Sent: vrijdag 5 mei 2000 17:54
To: http-wg@hplb.hpl.hp.com
Subject: RE: Using Chunked encoding to send control messages to a client


kugler@us.ibm.com 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
> be much different (you'd get all parts of the response at
> once).

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
msabin@cromwellmedia.com          http://www.cromwellmedia.com/

Received on Monday, 8 May 2000 11:54:04 UTC