Re: Focusing our discussion on issues

Also I should include a reference to the definition of the Upgrade header, which has a specific example for a hypothetical HTTP/2.0:

    http://tools.ietf.org/html/rfc2616#section-14.42

and the updated version here:

    http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-24#page-56


On Nov 15, 2013, at 10:36 AM, Michael Sweet <msweet@apple.com> wrote:

> +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
> 
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Friday, 15 November 2013 15:55:17 UTC