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

Or 3b, Intermediary receives HTTP/2 response headers containing a Content-Length, and it just dumps the DATA payload into the TCP connection as it arrives.  If the CL is incorrect, that's the origin's problem/fault.  But yes, at the transition point, prohibiting Transfer-Encoding strongly suggests that the absence of Content-Length implies creating the chunks off the DATA frames.

-----Original Message-----
From: Osama Mazahir [mailto:OSAMAM@microsoft.com] 
Sent: Wednesday, August 6, 2014 5:35 PM
To: Mark Nottingham; Michael Sweet
Cc: Zhong Yu; Martin Thomson; Johnny Graettinger; HTTP Working Group
Subject: RE: legality of Transfer-Encoding: chunked bodies in HTTP/2

So we are forcing 1.1<-->2.0 intermediaries to transform the body by stripping & adding chunked encoding instead of merely encapsulating the body into DATA frames?

1. Intermediary receives HTTP/1.1 chunked request body.  Intermediary strips "Transfer-Encoding: chunked".
2. Intermediary strips chunk headers as it constructs the DATA frames.  The final 0-chunk maps to an END_STREAM.
3. Intermediary receives HTTP/2 response body consisting of DATA frames (no "Transfer-Encoding: chunked").
4. Intermediary adds chunk boundaries as it constructs the DATA frames.  The END_STREAM maps to the final 0-chunk.

I'm confused.  Either "Transfer-Encoding: chunked" is illegal and intermediaries MUST convert or it's legal and HTTP2 receivers have to be able to handle "Transfer-Encoding: chunked".

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net]
Sent: Tuesday, August 5, 2014 9:25 PM
To: Michael Sweet
Cc: Osama Mazahir; Zhong Yu; Martin Thomson; Johnny Graettinger; HTTP Working Group
Subject: Re: legality of Transfer-Encoding: chunked bodies in HTTP/2

Just to make sure we're all on the same page -- *logically* HTTP/2 is still chunked, because you still split things up into DATA frames. However, the "chunk" format specified in <http://httpwg.github.io/specs/rfc7230.html#chunked.encoding> will NOT be considered part of the message framing in HTTP/2; if that shows up, it'll be considered payload (and therefore visible to the application as content, which is probably NOT what you want).

Cheers,


On 6 Aug 2014, at 10:32 am, Michael Sweet <msweet@apple.com> wrote:

> DATA frames are already equivalent to HTTP/1.1 chunking.  Why do we need to chunk twice?
> 
> On Aug 5, 2014, at 5:00 PM, Osama Mazahir <OSAMAM@microsoft.com> wrote:
> 
>> +1 for allowing Chunked.
>> 
>> Windows machines are going to end up output chunked responses (well...technically anything built on top of the Windows HTTP networking components).  We cannot rewrite all the Windows applications to avoid chunking and having some magical translation layer doing unbounded buffering to convert into Content-Length prefixed form is bad.  Stripping the chunk boundaries when encapsulating into DATA frames requires a reparser in the data send path, which is merely swapping one problem for another (and may require the peer to do the opposite if converting back into 1.1 form).
>> 
>> It may be _ineffecient_ to have chunks but it should be legal, to maximize 1.1<-->2.0 fidelity.  
>> 
>> We can probably address this via editorial changes indicating that in pure HTTP2, using END_STREAM only is the preferred way to mark end-of-body (or, of course, trailers).  Along with all the normal caveats of smuggling bytes in DATA frames after the final chunk, etc.
>> 
>> -----Original Message-----
>> From: Zhong Yu [mailto:zhong.j.yu@gmail.com]
>> Sent: Tuesday, August 5, 2014 1:30 PM
>> To: Martin Thomson
>> Cc: Johnny Graettinger; HTTP Working Group
>> Subject: Re: legality of Transfer-Encoding: chunked bodies in HTTP/2
>> 
>> On Tue, Aug 5, 2014 at 3:09 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>>> On 5 August 2014 11:39, Johnny Graettinger <jgraettinger@chromium.org> wrote:
>>>> Section 8.1.3 "Examples" provides guidance on how an intermediary 
>>>> should do so, however section 8.1.2.2 "Hop-by-Hop Header Fields"
>>>> says that stripping Transfer-Encoding is a SHOULD, not a MUST.
>>> 
>>> Yeah, so the only reason that it's not a MUST is that some 
>>> intermediaries don't look and we don't want to force them to look.
>>> That's all.  Transfer-Encoding has no meaning in HTTP/2 (unless an 
>>> extension restores that meaning).
>>> 
>>> Seeing the chunked framing in DATA frames would be wrong.
>>> 
>> 
>> That is quite confusing and dangerous. Should we require that anyone
>> *generating* the initial HTTP2 message MUST NOT include the Transfer-Encoding header?
>> 
>> Zhong Yu
>> bayou.io
>> 
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 7 August 2014 01:16:44 UTC