W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1999

RE: IPP> Chunked POST

From: <kugler@us.ibm.com>
Date: Tue, 17 Aug 1999 17:23:28 -0600
To: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>
cc: http-wg@hplb.hpl.hp.com
Message-ID: <872567D0.00809013.00@d53mta08h.boulder.ibm.com>

>Actually they are quite distinguishable. A HTTP/1.1 client, who expects all
>1.1 servers to support chunked transfer, would probably become hopelessly
>confused by server B's behavior and thus be unable to communicate with
>server B.

But the behavior, as seen from the client, is the same in either case!

>The key here is that the "length required" error would not tip off the 1.1
>client that it shouldn't use chunked transfer because in so far as the 1.1
>client is concerned using chunked transfer does provide length information
>so therefore the error's requirement has been met.

No, the 411 specifically says "The server refuses to accept the request without
a defined Content-Length. The client MAY repeat the request if it adds a valid
Content-Length header field containing the length of the message-body in the
request message."  The 411 means that the client must provide a Content-Length
header, not just the length information embedded in the chunked transfer-coding.
Of course, if the client does provide a Content-Length header, then it must use
the "identity" transfer-coding.

>Thus failing to support chunked transfer in a 1.1 server prevents
>interoperability, which is the very definition of non-compliance.
>              Yaron
>> -----Original Message-----
>> From: Carl Kugler [mailto:kugler@us.ibm.com]
>> Sent: Tue, August 17, 1999 3:54 PM
>> To: http-wg@hplb.hpl.hp.com
>> Subject: Re: IPP> Chunked POST
>> > Re: IPP> Chunked POST
>> >
>> > Roy T. Fielding (fielding@kiwi.ics.uci.edu)
>> > Thu, 17 Dec 1998 22:03:24 -0800
>> >
>> --------------------------------------------------------------
>> ----------
>> >
>> > >In my opinion, Ken Coar is correct in saying that for a server to
>> > >be *both* HTTP/1.1 compliant and CGI/1.1 compliant it MUST buffer
>> > >chunked POST data and provide a Content-Length for the CGI script.
>> >
>> > 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 "chunked" transfer-coding.
>> > ...
>> http://www.ics.uci.edu/pub/ietf/http/hypermail/1998q4/0210.html
Received on Wednesday, 18 August 1999 00:26:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:23 UTC