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

Larry
--
http://www.parc.xerox.com/masinter


> -----Original Message-----
> From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
> Sent: Wednesday, August 18, 1999 8:00 AM
> To: Roy T. Fielding
> Cc: http-wg@hplb.hpl.hp.com
> 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