- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 6 Aug 2014 14:25:20 +1000
- To: Michael Sweet <msweet@apple.com>
- Cc: Osama Mazahir <OSAMAM@microsoft.com>, 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>
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 Wednesday, 6 August 2014 04:25:52 UTC