- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 30 Mar 98 10:32:56 PST
- To: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
Imagine for a moment that I have a proxy server. I start to fetch
a page for a client, and return the headers. There are many
objects that don't come with Content-Length (e.g. FTP).
If it is not cacheable I won't buffer it; even if it is cacheable,
the first client doesn't get a Content-Length because I don't
buffer the entire object before sending the response (to reduce
latency).
Imagine the request times out, or a shark eats the trans-Atlantic
cable the object is being transfered over, or whatever. Now, I
have to close the connection to the client, who recieves a
truncated object with no indication of an error (until he tries to
use it and finds it is corrupted). There is no possiblity of
reporting what the problem is either.
Maybe I'm missing something, but this seems like an ideal scenario
for "Chunked". The proxy doesn't have to buffer the entire file,
but it can buffer pieces thereof (say, 8KB chunks, 1KB chunks,
whatever). Since the Chunked transfer-encoding does have a mechanism
to indicate end-of-content (i.e., sending a zero-length chunk), it's
now unambiguous whether the client has received a truncated object
or not.
Of course, if the client doesn't speak HTTP/1.1, then you can't
use "chunked". But this is the situation today, right?
An HTTP/1.1 proxy could (in theory) buffer the entire entity-body
if it knows that the client doesn't understand "chunked". But I'm
not sure this is really the right approach, since I suspect it
will simply lead to bored HTTP/1.0 users hitting "stop" and "reload",
and that isn't something we should encourage.
-Jeff
Received on Monday, 30 March 1998 10:34:32 UTC