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

On 11 Jul 2014, at 8:05 pm, Amos Jeffries <squid3@treenet.co.nz> wrote:
>> 
>> 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.

Not following you here...


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

Yes, but we’re discussing ways around that...


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

See other comments today about “bleh” arguments :)


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

Greg may not be so alone any more; see Jeff’s thread.

Cheers,



--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 11 July 2014 10:56:52 UTC