Re: #555: frame synchronization

I’ll stand up against it. 

It’s added complexity and added thing to check, and this is not to recover from a network mis-hap, but from an implementation bug. And such implementation bugs are bound to be discovered in stress testing (everybody stress-tests their implementations, right?)  These bugs can happen not only at the edges, but also in intermediaries that mess with the streams, but still, this is something that is bound to happen in testing.

If a frame gets unread, a stream will get pre-maturely ended. This will lead to a protocol error and a GO-AWAY. So Martin’s “pretty quickly” is bounded by the lifetime of a single stream, which should be short enough.

If the stream does not include the content-length header, then the stream will appear to end correctly, but the resource will be missing a piece. That will not be detected, but hopefully this will get detected by the application. I guess an HTTP/1.x implementation could “miss” a TCP segment and get a bad resource. I don’t think this justifies a new integrity mechanism. If anything we might want a resource hash/integrity/checksum field rather than a per-frame field. But that is an idea for another thread.

Yoav


On Jul 21, 2014, at 10:35 AM, Mark Nottingham <mnot@mnot.net> wrote:

> I’m only hearing PHK and Kinkie argue for this, and the people I’m seeing F2F in Toronto are against it. 
> 
> Considering how big of a change this is, I don’t think there’s enough support to get it over the wall.
> 
> Anyone else want to stand up for it?
> 
> 
> On 21 Jul 2014, at 10:19 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
>> In message <CA+Y8hcPt1RZfhV3NmqiPdmfNN_=nSn1v_KOrpGiZ1UYJBu_g4A@mail.gmail.com>
>> , Kinkie writes:
>>> On Mon, Jul 21, 2014 at 3:27 PM, Michael Sweet <msweet@apple.com> wrote:
>>>> Generally I think this is unnecessary - HTTP depends on "reliable" transport (TCP as defined) so we probably don't need this for frames generally.
>>> 
>>> To me the most obvious advantage is not about data corrupted/lost by
>>> transport, but in rapid detection of buggy http2 implementations in
>>> peers.
>> 
>> +1
>> 
>> -- 
>> 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.
>> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
>

Received on Monday, 21 July 2014 22:29:06 UTC