Re: IPP> Chunked POST wrote: 
original article:
> >> 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
> >request that does not include a "Content-Length" header.  This is a
> >server.
> >
> >Server B understands no transfer-coding except "identity".  It
cannot receive
> >or decode the "chunked" transfer-coding.  It sends a 411 "Length
> >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
> >through their external interfaces, they are virtually
> >(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
> then I'd agree with you.  The reason it is there is to prevent an
> application from mistakenly thinking the chunked encoding is *no*
> and saving the chunk-sizes as part of the data.  As far as the
> is concerned, recognizing Transfer-Encoding chunked, and responding
> 411 and connection close, is equivalent to parsing the chunked
> Nobody is going to prevent you from building a server that responds
> 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
> (only things that won't interoperate with others via HTTP).

Isn't that what Apache does with chunked POSTs?

> ....Roy

Received on Thursday, 19 August 1999 21:18:25 UTC