- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 9 Jul 2015 23:29:35 +0200
- To: Zhong Yu <zhong.j.yu@gmail.com>
- Cc: RFC Errata System <rfc-editor@rfc-editor.org>, "Roy T. Fielding" <fielding@gbiv.com>, Julian Reschke <julian.reschke@greenbytes.de>, Barry Leiba <barryleiba@computer.org>, Mark Nottingham <mnot@mnot.net>, Rick Taylor <rick@tropicalstormsoftware.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 Thursday, 9 July 2015 21:31:29 UTC