- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 18 Jul 2014 08:11:33 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Mark, On Fri, Jul 18, 2014 at 10:44:34AM +1000, Mark Nottingham 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) I'd prefer a) but I think I can possibly live with b) (would be better with the requirement that CONT are only allowed after full header frames). I'm saying "I think" because I'm seeing comments from people who seem violently against either option that I don't understand so I'm wondering if I'm missing something. To be clear: I want my receiver to be able to announce its limits (ideally the uncompressed set, but also the max frame size), and not to have to deal with these CONT frames which can block everything, or can force the receiver to decompress one byte at a time. My understanding of your proposal is that a) covers the second part and partially the fist one, and that b) covers the first one only. Willy
Received on Friday, 18 July 2014 06:11:58 UTC