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 14:20:46 UTC