Subject: RE: IPP> Chunked POST

From: [email-masked]
Date: Tue, 17 Aug 1999 17:23:28 -0600

>
>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:[email-masked]]
>> Sent: Tue, August 17, 1999 3:54 PM
>> To: [email-masked]
>> Subject: Re: IPP> Chunked POST
>>
>>
>> > Re: IPP> Chunked POST
>> >
>> > Roy T. Fielding ([email-masked])
>> > 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
>>

---

From: [email-masked]
Date: Wed, 18 Aug 1999 09:38:14 -0600

>To: "Roy T. Fielding" <[email-masked]>
>cc: [email-masked]
>>>This is a meaningless distinction.  Consider this thought experiment:  we
have
>>>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?
>
Oops, just realized after sending this that it won't do for the client to close
the connection, since it would never be able to get a response.  So the only
real interoperable option is Content-Length/identity.

>     -Carl
>>....Roy

---

From: [email-masked]
Date: Wed, 18 Aug 1999 08:25:11 -0600

My point is that on the server side, it's a meanless MUST.  An ostensibly
HTTP/1.1 compliant server can always (legally) respond with 411 whenever it
encounters a chunked request.  Then there is no way to tell (short of taking
apart the server) whether or not the server is actually capable of receiving and
decoding the chunked transfer-coding.  This seems to be a widely exploited
loophole.

     -Carl

"Yaron Goland (Exchange)" <[email-masked]> on 08/17/99 05:51:56
PM

To:   Carl Kugler/Boulder/IBM@IBMUS, "Yaron Goland (Exchange)"
      <[email-masked]>
cc:   [email-masked]
Subject:  RE: IPP> Chunked POST

All requirements must be taken within the context of the over all standard.
Given that the standard requires Chunked at a MUST level it is fair to
interpret that requirement as over riding an optional response code.

          Yaron

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tue, August 17, 1999 4:23 PM
> To: Yaron Goland (Exchange)
> Cc: [email-masked]
> Subject: RE: IPP> Chunked POST
>
>
>
>
> >

---

From: [email-masked]
Date: Thu, 19 Aug 1999 08:50:00 -0600

Right, a client can interoperate with any server as long as it sticks to
Content-Length.  But if it cannot determine the message length in advance it's
probably SOL.

     -Carl

"Roy T. Fielding" <[email-masked]> on 08/18/99 11:59:21 PM

To:   Larry Masinter <[email-masked]>
cc:   Carl Kugler/Boulder/IBM@IBMUS, "Yaron Goland (Exchange)"
      <[email-masked]>, [email-masked]
Subject:  Re: IPP> Chunked POST

>We might make replying '411 and connection close' to a chunked encoding
>'conditionally compliant' rather than 'compliant' because otherwise,
>as has been pointed out, there are inteorperability problems.

There is no interoperability problem here.  The server response is
understandable by the client.  Any server has the right to deny
service rather than buffer an unknown amount of data.  No change is
needed to the spec.

....Roy

---

From: [email-masked]
Date: Fri, 20 Aug 1999 12:10:28 -0600

I don't want to implement a new protocol service using CGI.  But I'm worried
about things like proxies refusing to forward chunked requests.

I haven't kept up with the Jakarta thing, but it will be interesting to see if
the Apache Java servlet implementation supports chunked POST.

     -Carl

"Roy T. Fielding" <[email-masked]> on 08/20/99 11:47:01 AM

To:   Carl Kugler/Boulder/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: IPP> Chunked POST

>Isn't that what Apache does with chunked POSTs?

No.  It is what mod_cgi requires.  Apache implements chunked in the core,
where any module can make use of it if they so desire.

As I've said many times before, implementing a new protocol service
using CGI is a bad idea.  Making HTTP requirements based on the limitations
of CGI is even worse.

....Roy