Re: #541: CONTINUATION

In message <5AA33CBC-DC1C-4B5B-BF70-5891B7A36A34@mnot.net>, Mark Nottingham writes:
>
>On 3 Jul 2014, at 4:29 pm, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
>> On 2014-07-03 00:29, Poul-Henning Kamp wrote:
>>> PPS:
>>>    I'm looking for co-authors for a jumboframe extension draft.
>> 
>> Do you really need them? if you publish a sensible draft I expect 
>several of us not liking CONTINUATION would implement.
>
>Would you (or any of the other Jumbo advocates) mind explaining why on 
>its own it's better than CONTINUATION, beyond syntactic sugar?

For HEADERS it will tell the server up front how long the headers
are going to be (in compressed form) and this will aid memory
management and DoS resistance.

For DATA it will improve transmission efficiency, both in terms
of bandwidth and overhead for large objects.

As seen by the pull request offered as part of another proposal,
the entire draft becomes significantly shorter and simpler to
implement once all the special-casing of CONTINUATION disappears.

A side effect of getting a SETTING for largest frames accepted will
aid also sites that want to restict HEADER or frame sizes and provide
early warning of things that are simply not going to work because
of restrictions at the peer.  Today there is no way for HAproxy or
Varnish to say "Don't even try larger than X bytes".

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Thursday, 3 July 2014 07:55:15 UTC