Re: Focusing our discussion on issues

On 15.11.2013 16:36, Michael Sweet wrote:
> +1.
> FWIW, there exists (and is widely implemented, at least with CUPS and printers) the HTTP Upgrade to TLS mechanism (RFC 2817 - that allows a client, server, or proxy to force encryption of that connection.  This isn’t a replacement for end-to-end TLS (https://) but perhaps points to a better way for HTTP/2.0 to interoperate with proxies and solve item B below.
> To summarize, a HTTP/2.0 capable user agent wanting to display the contents of “” can include an Upgrade header in its initial HTTP/1.1 request, for example:
>      GET /index.html HTTP/1.1
>      Host:
>      Upgrade: HTTP/2.0
> A proxy that receives this does not (or at least is not supposed to…) forward the Upgrade header, and can either respond with 101 Switching Protocols if it supports HTTP/2.0 or ignore the header and return a HTTP/1.1 response (cached or otherwise).
> Similarly, proxies that support HTTP/2.0 could include their own Upgrade header when sending a request to the server or next proxy, doing the same upgrade dance.
In the current HTTP/2 draft the upgrade is used to upgrade from HTTP/1 
to HTTP/2, but still in text form. Your proposal is to use upgrade to 
TLS and use ALPN to go to HTTP/2 over TLS? This seems fine to me. The 
question I asked already earlier is the goal to have an end to end 
(whatever this means) connection to tunnel through the internet or is 
the goal to use TLS to the next hop.
> The advantage here is that we always start with HTTP/1.1 (compatibility with proxies) but opportunistically upgrade to HTTP/2.0 when supported.
I think there should also be a way to directly do HTTP/2.

> The same mechanism can be used for https://, and may in fact be needed given that we now know that MITM https:// proxies are widely deployed and could likely have the same limitations as http:// proxies.
> Thoughts?
> On Nov 15, 2013, at 3:45 AM, Poul-Henning Kamp <> wrote:
>> In message <>, Mark Nottingham wri
>> tes:
>>> We've seen a lot of discussion of the proposed response to pervasive
>>> monitoring, as well as a number of new participants (welcome!).
>>> The volume (in both senses of the word) of this discussion was perhaps
>>> predictable, but it doesn't help us move forward.
>> First, I think everybody needs to step away from the keyboard and
>> re-read the chapter named "Second Systems Syndrome" in The Mythical
>> Man-Month.
>> By all means read all of the book while you're at it, and don't
>> worry if it will take you some days to buy the book first:  It will
>> save you much more time later in life.
>> Presently people are trying to make HTTP/2.0 resolve all their
>> current grieveances, be they related to HTTP or not, by cramming
>> their particular agenda into the proposed protocol.
>> That is not going to give us a good new protocol, certainly not
>> soon and likely not ever.
>> I motion that we call a timeout while people read up on their
>> classics, and propose that the WG:
>> A)      Define a successor to HTTP/1.1, which moves HTTP objects
>> 	across *any* transparent byte-pipe with better performance
>> 	than HTTP/1.1.
>> B)	If sensible, define an upgrade mechanisem from HTTP/1.1 to
>> 	the new protocol, that reuse the underlying byte-pipe.
>> C)      Decide that discussions about selection of, and mapping of
>> 	URI scheme to, byte-pipe carriers, is unnecessary and
>> 	unproductive.
>> In re A:  Emphasis on *any*, if we can't beat HTTP/1.1 on *any*
>> 	  connection, we're not doing a good enough job.
>> In re B:  This has proven much harder in terms of protocol-trickery,
>> 	  port 80 is a lot less of transparent byte-pipe in
>> 	  practice than some of us expected and it costs us a
>> 	  performance hit during startup.
>> In re C:  If we design HTTP/2.0 to be encryption agonistic, it
>> 	  will not go down when any particular encryption protocol
>> 	  policy sinks.  There is no point and no benefit in tying
>> 	  ourselves to the mast
>> Thanks,
>> -- 
>> 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.
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Friday, 15 November 2013 16:34:56 UTC