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?

     -Carl

>....Roy
>