- From: <kugler@us.ibm.com>
- Date: Wed, 18 Aug 1999 09:38:14 -0600
- To: http-wg@cuckoo.hpl.hp.com
- cc: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>, http-wg@hplb.hpl.hp.com
>To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu> >cc: http-wg@hplb.hpl.hp.com >Subject: Re: IPP> Chunked POST > > > > > > > >> >>>> Sending 411 is HTTP/1.1 compliant. Failure to parse the chunked >>>> encoding (and puking) would be non-compliance, but requiring a >>>> content-length for a given resource is necessary for many reasons >>>> (DoS and legacy system protection). >>> >>>This is a meaningless distinction. Consider this thought experiment: we have >>>two HTTP servers, A and B. >>> >>>Server A can and does parse the chunked encoding. But it sends a 411 "Length >>>Required" response with a "Connection: close" header in response to any >>>request that does not include a "Content-Length" header. This is a compliant >>>server. >>> >>>Server B understands no transfer-coding except "identity". It cannot receive >>>or decode the "chunked" transfer-coding. It sends a 411 "Length Required" >>>response with a "Connection: close" header in response to any request that >>>does not include a "Content-Length" header. This is a non-compliant server. >>> >>>If we look at these servers as black boxes, observing their behavior only >>>through their external interfaces, they are virtually indistinguishable >>>(unless we look at the product tokens or something). So it's meanless to say >>>that all HTTP/1.1 applications that receive entities must understand (be able >>>to receive and decode) the =93chunked=94 transfer-coding. >> >>If the purpose of the text was to delineate one lame example from another, >>then I'd agree with you. The reason it is there is to prevent an HTTP/1.1 >>application from mistakenly thinking the chunked encoding is *no* encoding >>and saving the chunk-sizes as part of the data. As far as the protocol >>is concerned, recognizing Transfer-Encoding chunked, and responding with >>411 and connection close, is equivalent to parsing the chunked encoding. >> >>Nobody is going to prevent you from building a server that responds with >>411 to every request without implementing chunked. It would be a dumb >>thing to do, but the standard doesn't prevent people from doing dumb things >>(only things that won't interoperate with others via HTTP). >> >That's the clarification I was looking for. [Not that it's good news.] > >So, for interoperability, a client always needs to be prepared to fall back to >Content-Length with "identity" transfer-coding, and it's just plain out of luck >(or at least forced to buffer) if it cannot determine the message length in >advance. Or should it fall back to HTTP/0.9 behavior and signal the end of the >message by closing the connection? > Oops, just realized after sending this that it won't do for the client to close the connection, since it would never be able to get a response. So the only real interoperable option is Content-Length/identity. > -Carl > >>....Roy >> > >
Received on Wednesday, 18 August 1999 08:45:11 UTC