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