Re: Focusing our discussion on issues

+1.

FWIW, there exists (and is widely implemented, at least with CUPS and printers) the HTTP Upgrade to TLS mechanism (RFC 2817 - http://tools.ietf.org/html/rfc2817) 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 “http://www.example.com/index.html” can include an Upgrade header in its initial HTTP/1.1 request, for example:

    GET /index.html HTTP/1.1
    Host: www.example.com
    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.

The advantage here is that we always start with HTTP/1.1 (compatibility with proxies) but opportunistically upgrade to HTTP/2.0 when supported.

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 <phk@phk.freebsd.dk> wrote:
> In message <242B6E8E-BC39-44A0-8668-EEBDEBE4A416@mnot.net>, 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 15:36:50 UTC