Re: #540: "jumbo" frames

So if we can boot efficient transfer of large payloads to an extension, can
be we also punt large headers to an extension?

I get it that we are late in the process and have already got a some
experience with the current implementations - but seriously how much real
usage have continuation frames got? or will get in the near future?  Have
servers that support CONTINUATIONS been tested for DOS attacks from 1 byte
CONTINUATION frames?

cheers



On 25 June 2014 21:41, Nicholas Hurley <hurley@todesschaf.org> wrote:

> Accidentally hit regular reply instead of reply all on this one... (sorry
> for the dupe, Jason)
>
> On Wed, Jun 25, 2014 at 12:38 PM, Nicholas Hurley <hurley@todesschaf.org>
> wrote:
>
>> On Wed, Jun 25, 2014 at 11:55 AM, Jason Greene <jason.greene@redhat.com>
>> wrote:
>>
>>>
>>> Extensions are length limited to 16KB, so to allow that you would have
>>> to define special framing rules, and if you have done that might as well
>>> apply it everywhere.
>>>
>>
>> I don't see any text that says that.
>>
>>
>>>
>>> The rough proposals are trivial changes thought. We are talking about a
>>> small change to a length value and a new setting to negotiate.
>>>
>>
>> The same was true for both ALTSVC and BLOCKED - trivial, totally
>> ignorable frames (they didn't even have a setting associated with them,
>> IIRC)! But we removed them from the spec anyway, and agreed to make them
>> extensions, in favor of shipping it. There's no reason to block h2 for
>> something else that can be done as an extension.
>>
>
>


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