RE: IPP> Chunked POST

Maybe we're just missing an appropriate usage of "SHOULD" in the HTTP spec.

This needs another editing pass, but roughly:

"An HTTP/1.1 server SHOULD not only receive and interpret data with a
chunked encoding, it SHOULD treat chunked data as if it had received data
with Content-Length. Note, however, that some server implementations will
accept data with Content-Length but will reply with "411 Length Required"
to chunked data, at least for those URLs that are implemented via CGI 1.x[ref]
 because of CGI/1.x's requirement that the Content-length be supplied.
Even in those cases, it would be preferable for implementations to buffer
the data in order to compute the length to pass on to the CGI program."


> -----Original Message-----
> From: []
> Sent: Wednesday, August 18, 1999 8:00 AM
> To: Roy T. Fielding
> Cc:
> 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?
>      -Carl
> >....Roy
> >

Received on Thursday, 19 August 1999 01:06:11 UTC