Re: #541: CONTINUATION

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.
If that really is a meme, then we can't live with 0) and probably not 3).

I guess we need to put option 1) into the same group as 0) and 3). If we
can not implement continuation frames then we don't care if they are
compressed or not - we still will not implement a mechanism that is not
used by 99.99% of our users.

2) we obviously can live with.  However it is not my preference to not
support large headers.  I wish to support them with a seamless
implementation that is just a configuration change - ie jumbo frames.  A
large header extension is also OK.

Our preference is jumbo frames, as I believe they support large headers,
optionally support large data frames for the issue Willy brought up; and
they are no more complex and a lot less ugly than continuations.

But as jumbo frames have been ruled out as an option, we can live with 2).
We can live with 0), 1) and 3), so long as it does not become a crime (of
blackmail or otherwise) to not support CONTINUATIONs.

cheers

PS. If jumbo frames were to be at least considered I would undertake to
write up a full proposal for them.

















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