Re: IPP> Chunked POST

>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