RE: #541: CONTINUATION

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.

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.

  - 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.

  - 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.

-----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

Received on Wednesday, 2 July 2014 17:07:54 UTC