- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 9 Jul 2015 22:43:31 +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 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. What it says is how to process it if it is received : If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server. > I tested this response with five major browsers. All of them seem to know > to consume the response body till connection EOF. ( None of them knows how > to deal with the 'gzip' encoding; and if EOF arrives prematurely resulting > in a corrupted 'gzip' body, none of them detects it as a problem. ) Because they comply with the spec :-) > So it does work, sort of. Although, it seems preposterous; no server would > emit a response like that, right? That's exactly the point. The spec took a great care at explaining what must not be sent at all, and then how to deal with violations. The "message body length" section is 2-3 times longer than the equivalent one in 2616 for the exact same protocol, just because it aimed to cover all situations even the forbidden ones to make sure implementations don't run into vulnerabilities by missing something. Willy
Received on Thursday, 9 July 2015 20:44:14 UTC