RE: #541: CONTINUATION

What is "this" in your question?  I get the MAX_HEADER_BLOCK_SIZE proposal, and I'm suggesting that:
	- It refers to uncompressed header size, not compressed
	- The default is 16 KB; implementations that like that value need not send it.  (In fact, that's our out-of-the-box default, too -- it takes explicit configuration to increase the acceptable header size if your site needs it.)
	- CONTINUATION be constrained to following a max-size HEADERS, PUSH_PROMISE, or CONTINUATION frame; implementations that use the default value of MAX_HEADER_BLOCK_SIZE can reject a CONTINUATION frame from the client for violating one of several constraints.

Yes, this means waiting one RTT for large headers -- that's probably okay, since if our primary use-case is authentication, you need to wait one RTT to get challenged for auth to begin with.  (If you know in advance you need to auth, you may also know that the server supports large headers.)

The real question with such an extension is the reverse direction -- does the client also advertise their maximum response header size?  What should a server do if the request a client sent produces a response the client isn't going to accept due to header size?

-----Original Message-----
From: Jason Greene [mailto:jason.greene@redhat.com] 
Sent: Wednesday, July 2, 2014 11:36 AM
To: Mike Bishop
Cc: Greg Wilkins; Mark Nottingham; HTTP Working Group
Subject: Re: #541: CONTINUATION


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

Received on Thursday, 3 July 2014 01:20:34 UTC