- From: <kugler@us.ibm.com>
- Date: Wed, 18 Aug 1999 12:27:33 -0600
- To: "Yaron Goland (Exchange)" <yarong@exchange.microsoft.com>
- cc: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>, http-wg@hplb.hpl.hp.com
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