- From: Patrick McManus <pmcmanus@mozilla.com>
- Date: Fri, 18 Jul 2014 09:03:10 -0400
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNqd0biHiTR6pyCGaJEC5mnvyd5BW3woWABLF82CWP_A6A@mail.gmail.com>
My top preference is to close the issue with no action. My next preference is option [b]. In the best of all worlds it just adds new information about an existing problem (the existing implementation header limit) which is helpful. I very strongly dislike [a] for reasons already stated in this thread: http/1 tail compat and rewind. On Thu, Jul 17, 2014 at 8:44 PM, Mark Nottingham <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/ > > > > > >
Received on Friday, 18 July 2014 13:03:41 UTC