Re: A proposal

In message <2A7323E5-48BA-4E27-8E48-5C13C3374891@mnot.net>, Mark Nottingham wri
tes:

>So, this is effectively a proposal of how to upgrade plaintext HTTP/1 to 
>HTTP/2.

You can call it that, I saw it more as an attempt to call the party
to order and get back to business :-)

I thought, and that's probably just me being naiive, that our business
was something like:

	1. Design a HTTP/2.0 protocol which has awesome performance
	   and does what people need, making it an obviously desirable
	   upgrade.

	2. Define how it can be deployed in a smooth fashion, with
	   no havoc and minimum pain.

	3. Spend more time with the family.

My assumption with respect to item 2 was that we would aim for
something which required no effort outside the transport function,
ideally just:

	1. Upgrade your webserver/proxy/browser software
	(2. Punch missing hole in firewall)
	3. Profit!

And therefore it came as a total surprise for me, that people would
even consider adding a new URI scheme as part of HTTP/2.

That would for instance require CMS designers to change their code
so they can deliver old-style URIs to HTTP/1 clients (which would
not know what to do about the new ones) and new-style URIs for HTTP/2.

(And what to do about all the old content, do you need to go through
that and change the URIs ?)

I think it might be a timesaver to decide questions like this up
front, since it has pretty big architectural impact down the road,
and if we want to add URI schemes, we should alert the CMS people
at the earliest possible moment.


If SPDY is what we're going to goldplate into HTTP/2, I think my
proposal is basically sound, but it was hashed out in a matter of
minutes and there are som interesting corners, such as:

	What does "http://example.com:80/..." mean ?
	What does "http://example.com:100/..." mean ?
	And does that depend on you receiving that via HTTP/1 or /2 ?

But my real preference and proposal, is still that we ditch SPDY,
and attack the problem from scratch, somewhat along the what I
started to outline here: http://phk.freebsd.dk/words/httpbis.html

(That was written before I realized that the purpose of this WG was
to gold-plate SPDY and before the "Global War on Privacy" was
demasked, it would need a few tweaks to reflect my current thinking.)

Therefore I'm happy to see that other people have started pushing
for a more envelope/content based scheme which would allow fast
routing and per object cryptographic protection rather than per
session protection.

In addition to the performance benefits, I think that could make
HTTP/2 a much more politically acceptable protocol.

But I find it somewhat futile to move forward at the technical
level, if we can't even agree if the US government banning HTTP/2
should count as success or failure for the WG ?

Maybe we need revisit the "big lines" and agree, or at least
decide, what we're trying to do ?

But as Charles Schultz would have said it:

	  "It's your WG Mark Nottingham."

:-)

Poul-Henning

-- 
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 Monday, 18 November 2013 08:43:35 UTC