Re: Fragmentation for headers: why jumbo != continuation.

On 11/07/2014 5:57 p.m., Mark Nottingham wrote:
> 
> On 11 Jul 2014, at 3:50 pm, Greg Wilkins <gregw@intalio.com> wrote:
> 
>> 
>> On 11 July 2014 15:32, Mark Nottingham <mnot@mnot.net> wrote: 
>> Roberto isn't making a latency argument -- it's an argument for
>> minimal buffering in the optimistic case(s).
>> 
>> 
>> Servers have to hold the headers for the entire request handling
>> duration anyway (unless you throw away all the general purpose
>> servers that we currently have), so it makes no difference to their
>> buffering if the headers arrive in 1 or many fragments.
>> 
>> Proxies cannot forward headers in fragments because: • the routing
>> information may be in the last fragment. • because encoding mutates
>> the ref set, a proxy cannot commence sending headers until it has
>> all fragments, else it risks blocking the whole connection. Getting
>> rid of the ReferenceSet may fix 2 and help with 1 in special cases.
>> 
> 
> Roberto appears to be arguing that just because the routing
> information might be in the last fragment, it isn't always; that's
> pessimistic. If the necessary information is in the first, it can be
> acted upon and then forwarded, reducing the buffers necessary to
> serve this more optimistic case.

I believe its optimistic to expect malicious coders will write the
routing information in the last fragment if they find you have coded to
assume it is in the first one(s). Even if the spec says only to send in
the first fragment.

> 
> Likewise, on the response side, an intermediary can pass receive and
> then send fragments of headers, rather than buffering them.

*Unless* the connection is in use by any other client streams. At least
given the current draft definition of how CONTINUATION MUST NOT be
multiplexed. If it does so then it is HOL blocking the connection until
the last fragment/CONTINUATION is delivered.

> 
> I'm not taking a position here, BTW -- just trying to clarify the
> discussion. It also appears to be the crux of the argument regarding
> getting rid of or keeping CONTINUATION...

Yes. Multiplex meet CONTINUATION. Bleh.

> 
>> But I maintain that if we really want to fragment headers, then put
>> them in a segment of DATA frames rather than invent a second
>> mechanism.
> 
> Greg, you appear to be alone here...
> 

I agree with him on this. There is a very big "IF" at the start of the
sentence. That is the only way mentioned so far that avoids the issues
highlighted against multiplexed CONTINUATION and without using large frames.

Amos

Received on Friday, 11 July 2014 10:06:26 UTC