Re: Focusing our discussion on issues

And to answer a common offline question I’ve been getting, this is different from the current HTTP/2.0 draft in that the client does not send a Connection: Upgrade header, but instead relies on the server to do so in its response (server-initiated upgrade vs. client-initiated upgrade).  That at least gives server operators a better chance to turn off unencrypted HTTP/2.0 vs. relying on the client to know when it is “safe” to do so...


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

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

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Friday, 15 November 2013 19:35:47 UTC