RE: IPP> Chunked POST

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)" <yarong@Exchange.Microsoft.com> on 08/17/99 05:51:56
PM

To:   Carl Kugler/Boulder/IBM@IBMUS, "Yaron Goland (Exchange)"
      <yarong@Exchange.Microsoft.com>
cc:   http-wg@hplb.hpl.hp.com
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

> -----Original Message-----
> From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
> Sent: Tue, August 17, 1999 4:23 PM
> To: Yaron Goland (Exchange)
> Cc: http-wg@hplb.hpl.hp.com
> Subject: RE: IPP> Chunked POST
>
>
>
>
> >
> >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 Thursday, 19 August 1999 01:09:47 UTC