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).

....Roy