Subject: RE: IPP> Chunked POST

From: [email-masked]
Date: Wed, 18 Aug 1999 12:27:33 -0600

My point is that responding to Transfer-Encoding chunked by sending 411 and
Connection close is HTTP/1.1 COMPLIANT behavior.  By which I mean that it does
NOT violate HTTP/1.1.

My mileage does vary.  I have encountered product groups which refuse to take
the development and testing hit to make a server capable accepting chunked
POSTs, when it can legally reject them with 411.

     -Carl

"Yaron Goland (Exchange)" <[email-masked]> on 08/18/99 11:11:38
AM

To:   Carl Kugler/Boulder/IBM@IBMUS, "Roy T. Fielding"
      <[email-masked]>
cc:   [email-masked]
Subject:  RE: IPP> Chunked POST

You are free to implement whatever you want but I am certainly not going to
ask MS to take the development and testing hit to allow our clients to work
around servers which choose to knowingly violate HTTP/1.1.

     Your mileage may vary,

               Yaron

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

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 18 Aug 1999 16:28:05 PDT

> Connection close is HTTP/1.1 COMPLIANT behavior.  By which I mean that it does

...

> POSTs, when it can legally reject them with 411.

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.

This isn't an errata, but it belongs on the issues list.

On the other hand, a server can legally also reply '200 OK' to every POST,
and just ignore the data. A server can legally reply '404 Not Found' to
every GET, too! So the fact that there are some stubborn implementors
doesn't mean we should change the standard.

There is still a 'call' for an HTTP implementation guide; it isn't in the
charter of the HTTP working group, but this kind of advice might belong
there.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 18 Aug 1999 22:59:21 -0700

>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: Kyle Dent <[email-masked]>
Date: Thu, 19 Aug 1999 08:51:17 -0700

> service rather than buffer an unknown amount of data.  No change is

Quite right. Also, the fact that an implementation or product is 
compliant does not automatically mean that it is a good or 
even a fully featured implementation. 

Kyle Dent
<[email-masked]>
http://www.seaglass.com

---

From: Patrick McManus <[email-masked]>
Date: Thu, 19 Aug 1999 09:05:22 -0400 (EDT)

with the availability of 413 (request too large), 411 was not made
clear to me from the specification.. it's only from working with it
for the last year that I've come to some clarity on the topic, and who
knows if that's shared with other folks.

In a previous episode Roy T. Fielding said...
:: 
:: [..]  Any server has the right to deny
:: service rather than buffer an unknown amount of data.  

 a server does not commit to an all or nothing buffering process.. it
can buffer and if the request seems to be getting too large, it may
abort with 413...

requiring attempts at chunked processing never requires commitments to
unknown amounts of material. Each chunk is labeled with a length and
the server is free to send back 413 if the length of the upcoming
chunk pushes it over a threshold of that which it is willing to
buffer.

However, I can see that under some circumstances like CGI a server
might be unwilling to continue to buffer a chunked request at some
threshold (and it must be buffered because CGI requires a
content-length) but if it had come with a c-l it could be streamed to
the CGI, so 411 would seem to convey the feeling. 

However, making that threshold 0 is ridiculous. The vast majority if
CGIs take very little input.. there are exceptions of course but
presumably they can be designed in an environment that can either
afford the buffering or done with something other than CGI 1.1 that
doesn't have the CL problem.

the 411 distinction of "you must be capable of doing chunked, but you're
never actually required to do it" is too fine of a line in my
opinion.... but that's a retrospective, there really isn't anything
that can be done about it now even if we agreed the semantics for it
needed to be stronger. (and I suspect we don't agree.. que sera sera).

-P