W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

Re: [Technical Errata Reported] RFC7230 (4412)

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>
Message-ID: <20150709204331.GJ26380@1wt.eu>
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.

Received on Thursday, 9 July 2015 20:44:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:45 UTC