Re: A proposal

In message <CACuKZqE4DDsZif_WA+fguDFXEJwHbVUKt6FdC-2CMqR5dWgiHA@mail.gmail.com>
, Zhong Yu writes:

>As a web page author, how do I choose which scheme, http:// or
>http2://, to use for a link? Do I need to detect the browser version
>the page is rendered on?

Right now we have two schemes in common use:  "http" and "https"
and people in both ends of the HTTP connection interpret that 
(more or less) as "without privacy" and "with privacy" respectively.

This is counter to the IETFs ratified semantics of the scheme as
protocol selector for these two values, but I think we will shoot
ourselves big holes in the feet, if we try to press the IETF
view down over everybodys head, as a preconditition for using HTTP2.

The choice of HTTP/1 vs. HTTP/2 should be decoupled from the HTML
and from the browsers URL field, and therefore I cannot support
James proposal.

My counter proposal:

1. HTTP/2 on port 100 is always plaintext, which makes life easy
   for network people and is conceptually simple for everybody
   to understand.  It also does not need any RTT before HTTP/2
   performance benefits kick in.

2. Encrypted HTTP/2 will go over 443 (if SSL/TLS is used, otherwise
   I suspect that will need a new port too ?)  This makes life
   easy and is conceptually easy to understand too.

3. Servers or intermediaries which can do HTTP/2 (port 100 and/or
   443) can indicate this two ways:

   a) By sending a header in only the *first* HTTP/1 response on
      any connection.

      This new header must be listed in "Connection:" since protocols
      supported is by nature a hop-by-hop property.

      (For further study:  Make this a general purpose header which
      can also indicate HTTPS, SCTP or other protols supported ?)

   b) In DNS records. (For futher study:  How ?)

   Servers should do both. Intermediaries can only do a).

4. URIs in HTML documents do not change.

	"http:" means "no privacy needed"
	"https:" means "privacy required"

   The user-agent gets to resolve that into HTTP/1 and HTTP/2 (or
   any other protocols), according to policy, preference and custom,
   based on server provided information, possibly cached.

5. Upgrading a HTTP/1 connection on port 80 to HTTP/2 will not
   be supported, the risk of reducing web relibility is too high and
   it would add RTT costs before HTTP/2 performance benefits kick in.

6. Upgrading a HTTP/1 connection on port 443 to HTTP/2 is desired
   only if HTTP/2 cannot be a negotiated option during the TLS -
   handshake.  I don't know the answer to this one, it may for
   further study ?

-- 
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, 17 November 2013 19:59:09 UTC