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: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Wed, 6 Aug 2014 13:56:01 +0000
To: Michael Sweet <msweet@apple.com>, Osama Mazahir <OSAMAM@microsoft.com>
CC: Zhong Yu <zhong.j.yu@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, Johnny Graettinger <jgraettinger@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <23f39cbaa6674c74a2f9c4b3a5f0de0b@BL2PR03MB132.namprd03.prod.outlook.com>
Mostly for the case of 1.1->2 intermediaries.  If you receive a 1.1 message, you have two options:  Encode the headers and encapsulate the payload (if you know the payload will be valid), or perform transform work on the headers and payload.  The more work that has to be done in that transform, the more throughput suffers.  The ability to simply encapsulate the body rather than transforming it is less work for the intermediary.

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

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 "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
Received on Wednesday, 6 August 2014 13:56:35 UTC

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