W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1999

Re: IPP> Chunked POST

From: <kugler@us.ibm.com>
Date: Wed, 18 Aug 1999 09:38:14 -0600
cc: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>, http-wg@hplb.hpl.hp.com
Message-ID: <872567D1.0055F6AB.00@d53mta08h.boulder.ibm.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
>>>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
>(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
Received on Wednesday, 18 August 1999 16:41:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:23 UTC