Re: reserved flags and extensions

In message <20140713173740.GY8438@1wt.eu>, Willy Tarreau writes:

>> If we want a different framing, we should neg^H^H^H advertise it not in
>> HTTP/2?s SETTINGS frame, but in ALPN/Upgrade and call it HTTP/3 or HTTP/2.1. 

I think ALPN/Upgrade should be reserved for such major steps.  We
do not want to use such a big hammer for small steps like an improved
header-compressor or some other optimization.

Also, some protocol improvements (like CPU-heavy or large-state
compressions) might only be opened for once non-hostility has been
shown convincingly some way or other, and it would be best to not
require an entire new connection for that.

The problem with low-fidelity implementations is that they, as the
name says, are not going to pay a lot of attention to what we write
they should do.

We sort of have an unstated (should we?) principle so far of "I
allow but You choose" attitude to variance from the base protocol,
if we stick to that, all extensions/variances MUST be announced
in SETTINGS, but the other end is not obligated to actually use them.

Given that, low-fidelity proxies can simply strip anything from
SETTINGS they don't understand.

-- 
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 Sunday, 13 July 2014 20:36:47 UTC