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

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

From: Life is hard... and then you die. <Ronald.Tschalaer@psi.ch>
Date: Tue, 31 Mar 1998 06:12:45 +0200
Message-Id: <98033106124535@psiclb.psi.ch>
To: HTTP-WG@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/10

[Richard Gray wrote:]
> 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.

Thanx for the explanation. I guess the problem is that http provides no
way to differentiate between an application level error (after the header
has been sent) and a network level error; the former must be signaled via
the latter. Assuming that application level errors are not very common
this is probably not such a major issue. However, it's not very pretty.

[Jeffrey Mogule wrote:]
> 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.

I agree. Closing the connection prematurely on a chunked transmission
is probably the best way to go (when talking to HTTP/1.1 clients).

[Koen Holtman wrote:]
> Hmm, I always thought it would be possible to generate a tcp-level
> error (connection abort?) instead of closing the connection to the
> client in the normal way.  Wouldn't that tell the client that
> something is wrong?

Yes, it would, *IF* you can generate an abort - that's not always
possible.


  Cheers,

  Ronald
Received on Monday, 30 March 1998 20:20:55 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:05 UTC