W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1999

Re: IPP> Chunked POST

From: <kugler@us.ibm.com>
Date: Wed, 18 Aug 1999 09:00:29 -0600
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
cc: http-wg@hplb.hpl.hp.com
Message-ID: <872567D1.00528514.00@d53mta08h.boulder.ibm.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/527

>>> 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 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?


Received on Thursday, 19 August 1999 01:03:27 UTC

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