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

Re: legality of Transfer-Encoding: chunked bodies in HTTP/2

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 8 Aug 2014 16:50:47 +1000
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Osama Mazahir <OSAMAM@microsoft.com>, Michael Sweet <msweet@apple.com>, Zhong Yu <zhong.j.yu@gmail.com>, Johnny Graettinger <jgraettinger@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <2C672249-F5C0-45A2-920C-68FE8D4EF2E8@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>
Indeed. From <http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-8.1>:

>   3.  zero or more DATA frames containing the message payload (see [RFC7230], Section 3.3)

"payload" is a very specific term, and it is *not* processed for chunks.

Cheers,



On 8 Aug 2014, at 8:35 am, Martin Thomson <martin.thomson@gmail.com> wrote:

>   Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]),
>   Transfer-Encoding is a property of the message, not of the
>   representation...
> 
> I think that the reason this hasn't come up before is that it seemed
> obvious to everyone implementing HTTP/2 that it was the octets of the
> representation that go in DATA.
> 
> Since it seems that it is not equally obvious to everyone, how about I
> add a section on this subject.
> 
> On 7 August 2014 15:19, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
>> I think part of the problem is the definition of a "hop-by-hop" header.  Transfer-Encoding isn't removed and reapplied by each hop, and isn't mentioned by Connection: that I've noticed.  However, RFC 7230 says "any recipient along the request/response chain MAY decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding changes are made to the Transfer-Encoding field-value."
>> 
>> So it's not end-to-end, but I don't see it explicitly called hop-by-hop either.  (If I'm missing someplace, please point it out to me.)  The second paragraph does say that Transfer-Encoding SHOULD be removed.  However, SHOULD means someone might not, and there's no explicit text about decoding, just about removing the header.  (Decoding is a reasonable inference when removing the header, though, obviously.)
>> 
>> We chose not to follow the SHOULD, found a compatibility problem with someone else who treated it as a MUST, and that's the issue we're trying to resolve here.  If it's actually a MUST, we should fix the spec, lest someone else make the same mistake.  If it's actually a SHOULD, then we should fix Chrome.  It's just a matter of making the call.
>> 
>> -----Original Message-----
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> Sent: Thursday, August 7, 2014 2:53 PM
>> To: Osama Mazahir
>> Cc: Mark Nottingham; Michael Sweet; Zhong Yu; Johnny Graettinger; HTTP Working Group
>> Subject: Re: legality of Transfer-Encoding: chunked bodies in HTTP/2
>> 
>> On 7 August 2014 14:48, Osama Mazahir <OSAMAM@microsoft.com> wrote:
>>> If so, we need to add some inescapably obvious editorial text into the
>>> spec stating that "Transfer-Encoding: chunked" is illegal
>> 
>> http://http2.github.io/http2-spec/#rfc.section.8.1.2.2
>> 
>> The first paragraph is unequivocal enough, in my opinion.  But I wrote that, so I'll defer to others on this point.
>> 

--
Mark Nottingham   https://www.mnot.net/
Received on Friday, 8 August 2014 06:51:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC