Re: Getting to Consensus: CONTINUATION-related issues

Preference order:
- Z: hybrid of A+B*
- A
- B (can live with)

*Option Z (hybrid A+B): Remove CONTINUATION. No frame size limit on HEADERS/PUSH_PROMISE up to 2^24-1 (ie "unlimited headers" so no rewind necessary).  Compressed length is declared up front (ie buffer at sender). Advisory setting for uncompressed limit a peer is willing to receive (but might not imply PROTOCOL_ERROR or STREAM_ERROR on receipt)

-Keith


On Jul 18, 2014, at 7:09, "Rob.Trace@microsoft.com<mailto:Rob.Trace@microsoft.com>" <Rob.Trace@microsoft.com<mailto:Rob.Trace@microsoft.com>> wrote:

We prefer outcome B as this will allow us to continue to support existing 1.1 applications with HTTP/2.

While we can live with option a, it will cause us a lot of complexity both in terms of implementation and in terms of interoperability with existing 1.1 applications.  In option a, the receiver controls the maximum frame size not the sender, so we cannot “ask” for an allowance and we have to live with what the receiver offers.  To make this work realistically, the sender will either have to create a new platform limit for existing applications or will have to create potentially complicated compression “unwind” or “preview” functionalities.

Thanks!!

-Rob

From: Greg Wilkins [mailto:gregw@intalio.com]
Sent: Thursday, July 17, 2014 9:43 PM
To: HTTP Working Group
Subject: Re: Getting to Consensus: CONTINUATION-related issues


Prefer a)
Can live with b)

On 18 July 2014 10:44, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
We've had a rollicking discussion about the design tradeoffs in CONTINUATION, especially regarding HOL blocking and DoS considerations.

I see very little new information entering that discussion, and I think everyone has come to understand the tradeoffs. For a refresher, please see the wiki:
  https://github.com/http2/http2-spec/wiki/ContinuationProposals

I proposed two options the other day:

a) Remove CONTINUATION from the specification and add a new setting that dictates the maximum HEADERS/PUSH_PROMISE frame size (as distinct from max_frame_size) a peer is willing to receive. I.e., the setting refers to the compressed header size.

b) Keep CONTINUATION in the specification, 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).

Although there have been some tentative proposals for additional options since, I haven't heard a clamour for support for them, so I think these are realistically the ways we can go.

As stated before, there will no doubt be tweaking and adjustments made to these, but I think we're in a place where we can choose a general direction.

I'd like to hear:

1) Your preferred outcome (if any)
2) Whether you can live with the other option, and if not, why

"I have no preference" is useful information too.

If you indicate you can't live with one (or both) of the options, you MUST give a detailed, relevant reason as to why; omitting the reason means your "can't live with" will be ignored.

Thanks,

P.S. Please state *your* preference, not what you think the WG can live with.

P.P.S. This is not a call for more discussion; please resist replying to others' preferences.


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







--
Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Friday, 18 July 2014 05:27:38 UTC