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

Re: Options for CONTINUATION-related issues

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 17 Jul 2014 15:54:39 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <3AF63F93-743B-4875-A520-85009211BD4E@mnot.net>
To: Greg Wilkins <gregw@intalio.com>

On 17 Jul 2014, at 3:48 pm, Greg Wilkins <gregw@intalio.com> wrote:

> 
> On 17 July 2014 14:45, Mark Nottingham <mnot@mnot.net> wrote:
> > c) Remove CONTINUATION from the specification, allow HEADERS to be fragmented and add a new setting that advises the maximum header set size (i.e,. uncompressed) a peer is willing to receive (but might not imply PROTOCOL_ERROR or STREAM_ERROR on receipt).
> 
> For such an invasive change,
>  
> Well it is not all that invasive.  It is essentially continuations redone without the issues forced on it by hpack's RefSet.   But either way "invasive" is subjective not technical reason, just like "ugly".
> 
> I think we need more than a sentence.
>  
> The details have been put in the wiki as requested: "Remove CONTINUATIONS, Fragment HEADERS"
> https://github.com/http2/http2-spec/wiki/ContinuationProposals

From there:

"""
	 Remove the CONTINUATION frames.
	 Remove priority fields from the HEADERS frame, as these can be sent in a separate PRIORITY frame without concerns of fragmentation.
	 Deduct the HEADER frame sizes from the flow control window sizes, but do not block header frames due to flow control.
	 If it is desired to declare a maximum header size (for 551), then add a SETTINGS_MAX_HEADER_SIZE expressed in uncompressed bytes
	 Remove the header block fragment from the PUSH_PROMISE frame. Instead send the headers in a HEADERS+ frame sequence following the PUSH_PROMISE frame.
"""

That touches many parts of the spec, introducing the opportunity for potentially many new interoperability problems.

But let's cut to the chase. Would any of our current implementers consider trying this out?


> I also see getting consensus around that being very problematic.
> 
> Where?  I thought you asked us to put the proposals into the wiki with pros and cons?  The only con listed against this proposal is the suggestion that it may increase the DoS attack surface but that is disputed if it is a significant increase or not.      Can we have some more detail about what is "very problematic" otherwise it is impossible to refute arguments that are only given as meta-reasons.

That was my gut feeling, if the WG comes out in support of it, I'm happy to be proven wrong.

After all, you did say it was "unrealistic" and "tilt[ing] at this windmill" yourself, Greg.

Regards,


--
Mark Nottingham   https://www.mnot.net/
Received on Thursday, 17 July 2014 05:55:07 UTC

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