- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 8 Aug 2014 16:50:47 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- 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>
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