W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Stuck in a train -- reading HTTP/2 draft.

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Tue, 17 Jun 2014 20:42:59 +0000
To: Matthew Kerwin <matthew@kerwin.net.au>
cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1862.1403037779@critter.freebsd.dk>
In message <CACweHNDp=zcZRj9ZTH55KwhAvrjLzQ2hNKnwjduHxM6QFwMSOA@mail.gmail.com>
, Matthew Kerwin writes:

>> >> Page 36: SETTINGS synchronization
>> >> ---------------------------------
>> >>
>> >> This is utterly bogus.

>I agree with Martin. If I use my earlier per-frame compression as an
>example: say I send the equivalent of SETTINGS[TE:gzip]. Then I find my
>resources being starved, maybe I'm being zip-bombed, so I send
>SETTINGS[TE:gzip;q=0]. If I'm being polite, I continue to accept gzipped
>messages until I get the ACK; however if it is actually a DoS attack, the
>ACK may never come, so I start a timer and use SETTINGS_TIMEOUT to bail.

So how is this different from sending

SETTINGS[TE:gzip;q=0]PING[0xdeadbeef] and waiting for the PING response ?

My point is that 99% of the time the ACK is just wasted effort, so
we shouldn't make it the default.

At the very least give SETTINGS a flag "SEND_ACK" that people can
avoid setting when they don't care about ACKs.

>> >> I would allocate frame Type values so that the top bit indicates
>> >> "subject to flow-control" to simplify implementation.  Similarly
>> >> expending a bit to mark hop-to-hop frames would make life easier
>> >> for high performance implementations.
>>
>> SPDY effectively did that.  Given the status quo, I'm not sure that
>> (!type) and (type&mask) are measurably different performance-wise.
>>
>Wouldn't play nicely with extension frames; you'd need more rules about how
>to forward unrecognised end-to-end frame types (not currently possible),
>how to detect/mitigate jerks working around flow control ... actually, I
>thought extension frames were all flow controlled, but apparently not. We
>rely on extension authors to be honest and accurate about what extension
>frames are flow-controlled.

Encoding it in the allocated type would make that honesty automatic,
and life easier for high-speed implementations.

>> >> Page 50: Error messages
>> >> -----------------------
>> >>
>> >> The RFC should propose text-messages for presentation purposes
>
>The equivalent of reason phrases attached to status codes, or something
>richer?

Something your grand-aunt can read to you in the phone, but preferably
have a chance of understanding so she doesn't have to.

My fear is that she'll call and ask what she should do about:

	"My computers says says: REFUSED_STREAM: The endpoint refuses
	the stream prior to performing any application processing"

That's a prefectly good explanation for the programmer, but not for
an end user.  Experiences has shown that most programmers don't realize
there is a difference unless we make them aware of it.

-- 
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 Tuesday, 17 June 2014 20:44:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC