- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 3 Jul 2014 11:16:09 +1000
- To: Jason Greene <jason.greene@redhat.com>
- Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Let’s call this general direction #4; it seems worth pursuing. Thanks, On 3 Jul 2014, at 4:35 am, Jason Greene <jason.greene@redhat.com> wrote: > > Removing CC entries as requested by Mark N. > > On Jul 2, 2014, at 12:07 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > >> I like this, especially in combination with Willy's restriction of 0). CONTINUATION is only valid if the preceding frame was max_size (so it really is a continuation and not an arbitrary fragment), and there are optional settings that let a server advertise its limits. I dislike the unpredictability of HTTP/1.1 in this regard, and wouldn't mind an extension or option in the spec to make things more transparent. > > Thanks for the feedback. If I understand you correctly, you are suggesting this be optional? I was suggesting something more along the lines of SETTINGS_HEADER_TABLE_SIZE, that would be called something like SETTINGS_MAX_HEADER_BLOCK_SIZE, which would default to 16KB. If you combined it with Willy’s proposal that would mean no CONTINUATIONS by default. The big CON of this possible proposal is that the .02% case would have to wait for a SETTINGS ACK before it can send a mega header. On the other hand, not wanting to improve the QOS of .02% seems to be a popular sentiment. The main pro I am after is mitigating the HOL blocking aspects of the current draft, and some form of reasonable default restriction would do that. > >> >> I would suggest a few refinements, though: >> - HPACK is effective. We, at least, will be bounding on the *uncompressed* sizes, not the size that goes into the frame. > > That’s a good point, and is perhaps better information for the client. The primary goal I had in mind though was balancing streams. Once the full header block (Header + N continuations) exceeds the max 16kb frame size you start introducing a fairness problem. So it seemed simpler to base it on that. However, input length is just as effective at controlling that. > >> >> - We've been conflating total header set size and maximum size of a single header; both are commonly-used caps, but they're different things. We need op-codes to be able to cross frame boundaries, because individual headers can be larger than 16KB; we need CONTINUATION both for that, *and* because the total header set can be larger than 16KB even if no individual header is. We should advertise both, if we're trying to fix the ambiguity. > > OK I can see that being useful to individual end points. > >> >> - There have been concerns expressed about being too specific about your limits, lest people try to skate too close to them. Perhaps there should be a way to express undefined if someone wants legacy behavior for some reason. > > I have no qualms with that. > >> >> -----Original Message----- >> From: Jason Greene [mailto:jason.greene@redhat.com] >> Sent: Wednesday, July 2, 2014 7:19 AM >> To: Greg Wilkins >> Cc: Mark Nottingham; HTTP Working Group; Tatsuhiro Tsujikawa; Mike Bishop; Gábor Molnár; Patrick McManus; Shigeki Ohtsu; Ludin, Stephen; Johnny Graettinger; Hasan Khalil; Jeff Pinner; block.rxckin.beats@gmail.com; Adrian Cole; matsumoto_r@net.ist.i.kyoto-u.ac.jp; Cory Benfield; Daniel Stenberg; Flack, Martin; t@motd.kr; Jeroen de Borst >> Subject: Re: #541: CONTINUATION >> >> >> On Jul 2, 2014, at 6:30 AM, Greg Wilkins <gregw@intalio.com> wrote: >> >>> >>> Mark, >>> >>> thanks for re-opening this issue with a focus on what we can live with. >>> >>> For jetty's part we can live with 0) or 3), but are having increasing concerns about it with the suggestions like Will's of clients deliberately trying to break implementations that choose not to support continuations. >> >> Keep in mind that to be compliant 0 requires that you support continuations you can't opt out of them *even* if you have a 16KB length limit. >> >> 1) The spec allows a peer to send lots of tiny CONTINUATION frames (and it looks like even empty are allowed). Chunking intermediaries has come up as a use case for this. >> >> 2) Even if you reject headers due to size, a limitless number of CONTINUATION frames must still be processed to keep the connection alive. >> >> That said you are free to GOAWAY in DOS scenarios; however, it still stands that implementations can not opt-out and remain compliant. Even if someone promises they won't create a walled garden, there are no guarantees. >> >> I was thinking of proposing an option 4, where a setting is added that specifies a total header frame(s) length limit, and a default limit of 16KB. This eliminates the HOL problems by default, and lets venders choose how much of one they are willing to accept to allow some bigger frames in. I'd prefer fixing continuations or jumbo frames, but at least this keeps everyone who is against from being non-compliant, and allows intermediaries to avoid relaying stuff that will only be rejected. >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat >> >> > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 3 July 2014 01:16:41 UTC