RE: IPP> Chunked POST

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)" <yarong@Exchange.Microsoft.com> on 08/18/99 11:11:38
AM

To:   Carl Kugler/Boulder/IBM@IBMUS, "Roy T. Fielding"
      <fielding@kiwi.ics.uci.edu>
cc:   http-wg@hplb.hpl.hp.com
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: 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 Wednesday, 18 August 1999 12:56:38 UTC