W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: New draft; Content-Length

From: Mike Cowlishaw <mfc@vnet.ibm.com>
Date: Sat, 24 Dec 94 09:01:40 GMT
Message-Id: <9412240900.AA00231@hplb.hpl.hp.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> > One question which I don't think is covered: if a client sends a
> > header with more than one Content-Length line, should the server
> > return an error, use the first (or last) Content-Length encountered,
> > or just ignore all the Content-Length lines?
>
> Good question -- I'm not sure.  My gut feeling is that if it is received
> by the server (in a POST), the server should return a bad request error
> unless the lengths are identical.  For clients receiving it from a server,
> I would think the client should use the last one encountered.
> Does that sound reasonable?

Well, my server currently implements 'lazy receive' -- that is, it
only receives data that's actually needed by the script or filter.
For example, if the URI has a syntax error, the script may never do
anything that needs information from the header, and in that case the
header is not received at all.

Similarly, if the script asks for the Content-length, only
enough of the header is received and parsed to find the first
"Content-Length: xxx" line.  If the body data is requested, all the
header is received, of course, but parsing of the header can stop
when the length has been determined.

Hence from a pure efficiency/server point of view, I suppose I'd be
happiest if either the only the first was used, or the state was
(explicitly) undefined if more than one "Content-Length:"  were
specified.  Similar arguments apply to any Request Header fields that
are normally expected only once (such as "If-Modified-Since").  And
clients connecting to my server will get a slightly faster response if
any 'must be parsed for this request' fields are near the top of the
header.

Mike Cowlishaw
IBM UK Laboratories
Received on Saturday, 24 December 1994 01:03:17 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:10 EDT