W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: HTTP features w/ low 'implemented' and 'tested'

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Mon, 30 Mar 98 10:32:56 PST
Message-Id: <9803301832.AA14474@acetes.pa.dec.com>
To: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3
    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

    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.

Received on Monday, 30 March 1998 10:34:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:30 UTC