W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Getting to Consensus: CONTINUATION-related issues

From: David Krauss <potswa@gmail.com>
Date: Fri, 18 Jul 2014 15:30:28 +0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D8A42F0A-8AA6-49B5-9DA2-9E440269A505@gmail.com>
To: Mark Nottingham <mnot@mnot.net>

On 2014Ė07Ė18, at 1:37 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Option a- I find this option to be an extremely poor option. I hate it, it should not happen.
> It increases aggregate complexity while increasing the DoS surface as it would require state rewind in the compressor.
Mark, may limit violation in option A still allow recipients to either streaming-decode the rejected block, or GOAWAY? Always-GOAWAY or attempting to proceed as if the HEADERS never happened simply are not workable. But, I think the real vote here is about CONTINUATION, and nothing more detailed. (I tried to get details from the Wiki page, but canít find apples-to-apples in any of it.)

I favor option A because it provides a better sweet spot for simpler implementations. However, the spec should also be clear that the preferred intermediary behavior is to ignore MAX_FRAME/MAX_HEADERS and forward headers indefinitely. This works without CONTINUATION, since now we have jumbo frames.

I can live with option B because Iíll eventually do streaming anyway. But, given the discussions of the past few months, I donít believe that header streaming is a reasonable implementation requirement. Some folks just wonít be able, or motivated, to do it. In practice, CONTINUATION will be poorly supported, and B just devolves to A with a slightly more complicated binary format.

TL;DR: We added jumbo frames already, now letís require them to fix what they were supposed to fix.
Received on Friday, 18 July 2014 07:31:02 UTC

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