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

Received on Wednesday, 18 August 1999 05:16:38 UTC