- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 10 Jul 2015 21:15:26 +1200
- To: ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>
CC'ing Mark to make sure this is on his radar. This same text seems to keep coming up as errata (this is the third time IIRC) and as below it can even catch some of us WG regulars who know what its about. To me it seem that the core issue is the words 'request' and 'response' being semi-hidden in the long descriptive text. I wonder if it is worth putting in an eratta to have the paragraph split into two simpler paragraphs starting with words like "For requests ..." and "For responses ..." ? This is after all two different sets of handling criteria for different message types. It makes a fair bit of sense to have them in different clauses as the rest of the documents text generally does for similar things. Amos On 10/07/2015 9:29 a.m., Willy Tarreau wrote: > On Thu, Jul 09, 2015 at 04:11:10PM -0500, Zhong Yu wrote: >> On Thu, Jul 9, 2015 at 3:43 PM, Willy Tarreau <w@1wt.eu> wrote: >> >>> On Thu, Jul 09, 2015 at 01:33:46PM -0500, Zhong Yu wrote: >>>> The spec does allow a response like >>>> >>>> HTTP/1.1 200 OK >>>> Content-Type: text/plain >>>> Transfer-Encoding: gzip >>>> Connection: close >>> >>> No it does not allow it as chunked is not last. It's in 3.3.1 : >>> >>> If any transfer coding >>> other than chunked is applied to a request payload body, the sender >>> MUST apply chunked as the final transfer coding to ensure that the >>> message is properly framed. >>> >> >> This text talk about "REQUEST" only :) The next sentence talks about >> "RESPONSE" - > > Hmm yes, good catch, sorry! > >>> If any transfer coding other than chunked is applied to a response >> payload body, the sender MUST either apply chunked as the final transfer >> coding or terminate the message by closing the connection. >> >> >> Apparently, the text is prune to misreading. > > Indeed, I didn't pay attention, I tend to consider that the rule > applies to both directions, though the strict control in haproxy > clearly is only for the request, just as specified. > > So yes, the spec allows it and also specifies how to process it. > I doubt any server find it fun to play this game given that we > all know that connection-delimited bodies are prone to silent > truncation, but that doesn't mean no server does it. > > Regards, > Willy > >
Received on Friday, 10 July 2015 09:16:17 UTC