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

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.

Received on Thursday, 7 August 2014 22:20:04 UTC