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

Re: [Technical Errata Reported] RFC7230 (4412)

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Thu, 9 Jul 2015 13:33:46 -0500
Message-ID: <CACuKZqFVfNLcg_CPx6vpigXi=nvBMDcy1dpb6+CgjePU9=iVDw@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
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>
The spec does allow a response like

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: gzip
Connection: close

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. )

So it does work, sort of. Although, it seems preposterous; no server would
emit a response like that, right?

PS. If the response is "Transfer-Encoding: gzip, chunked" on a keep-alive
connection, the browsers know to demarcate the response body by chunk
framing. (Again, they don't deal with the "gzip")

Zhong Yu
Received on Thursday, 9 July 2015 18:34:13 UTC

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