- From: Greg Wilkins <gregw@intalio.com>
- Date: Wed, 16 Jul 2014 14:01:16 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NGkhi-N2gQdf6xwzb17Dy9g5HO8Q7Sj_8HhV4_JMF_ywg@mail.gmail.com>
Mark, I think that a declared header limit, regardless of exact semantics, should be declared in terms of uncompressed header size rather than header block size. We should be decoupling HTTP semantics from the framing layer and with all the other proposals being currently considered (large frames, fragmented headers, etc.) then I think we are hopefully moving away from having any header limits (implicit or explicit) related to the frame size. With regards to the change in semantics that you suggest, I'm fine with that. It really just means that it is not a protocol error for a sender to ignore the setting. cheers On 16 July 2014 13:41, Mark Nottingham <mnot@mnot.net> wrote: > A lot of the discussion around < > https://github.com/http2/http2-spec/issues/551> is around having a hard > limit for header block sizes in the protocol, and the resulting ways that > helps and hurts. > > I wonder if we can make a small adjustment to ease some of the pain. > Specifically, what if it were only advisory, and there were no default? > > I.e., instead of a setting with the semantic of "You MUST NOT send header > blocks larger than <x>", what if it were "If you send header blocks larger > than <x>, I'll very likely discard them (responses) / respond with a 431 > (requests)"? > > This makes it much more flexible; if a proxy sends this setting and sees a > client ignoring it, they have the choice of either soft-failing them (with > a 431), accepting the larger request, or hard-failing them > (ENHANCE_YOUR_CALM). > > It also seems more compatible with the way that HTTP/1 works. > > I think that doing this might address most of the cons listed at < > https://github.com/http2/http2-spec/wiki/ContinuationProposals#limit-header-block-size-via-a-setting > >. > > Thoughts? > > > -- > Mark Nottingham https://www.mnot.net/ > > > > > > -- Greg Wilkins <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.
Received on Wednesday, 16 July 2014 04:01:44 UTC