- From: Mike Cowlishaw <mfc@vnet.ibm.com>
- Date: Sat, 24 Dec 94 09:01:40 GMT
- 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 UTC