section 4.4 of 2616 defines message length pretty explicitly for
http/1.1 at least.. any message body that isn't 'chunked' and has a
content-length header field is defined by that length.. (content
length is rule #3 is a a set of rules in decreasing precedence.. EOF
is rule #5). EOF w/out content length is ambiguous.. did the
connection die or is that the whole document? EOF w/ CL and an
*incorrect* number of bytes definitely signals a problem.. probably
truncation during transfer and a client should definitely *not* use
the response..
this sounds like a server problem not a caching or replication
problem.. obviously mangled HTTP messages are an issue
everybody but aren't really a problem with them..
-P
In a previous episode Joe Touch said...
::
:: > To: Duane Wessels <wessels@ircache.net>
:: > cc: wrec@cs.utk.edu, webmaster@ISI.EDU
:: > Subject: Re: oh the irony
:: > X-Organization: Hewlett-Packard Laboratories
:: > Date: Sat, 31 Jul 1999 09:40:26 -0700
:: > From: John Dilley <jad@pimlico.hpl.hp.com>
:: >
:: ...
:: > I've heard anecdotal evidence of content length being incorrect
:: > in responses and browsers having to accomodate that.
::
:: Seems like a browser might not care - just read until EOF.
:: Ditto for caches. Why is it necessary to trust this information
:: in the header?
::
:: Joe
::
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:26 MST