W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: A proposal

From: Michael Sweet <msweet@apple.com>
Date: Tue, 19 Nov 2013 12:12:11 -0500
Cc: Mike Belshe <mike@belshe.com>, "Roy T. Fielding" <fielding@gbiv.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <E5D4FB63-5C85-4D18-9C78-54F386590114@apple.com>
To: James M Snell <jasnell@gmail.com>
James,

Mark’s proposal is the first one that could actually be expressed as a conformance requirement, but I’d also like to give the delayed plaintext HTTP/2.0 upgrade approach a try - to reiterate, don’t allow the client to perform an upgrade until it sees an Upgrade: HTTP/2.0 header from a server response.

My hope is that while some HTTP proxies are broken WRT the headers that are sent up from the client to the server, they may be more careful about the headers from the server that they return to the client.  And in many cases the proxy is generating its own response headers to provide cached content.

This would also provide a way to support HTTP/2.0 (plaintext) proxies in the future.

(it *would* be nice to know which HTTP proxies have problems with the current HTTP/2.0 upgrade approach so I/we can test the delayed upgrade approach…)


On Nov 19, 2013, at 11:38 AM, James M Snell <jasnell@gmail.com> wrote:

> On Tue, Nov 19, 2013 at 6:38 AM, Michael Sweet <msweet@apple.com> wrote:
> [snip]
>> 
>> I know you are trying to be dramatic here, but I don't think "think of the
>> children" arguments have any place here.
>> 
> 
> +1 ... honestly, this whole conversation seems to be getting lost in
> the weeds, really. Personally, I don't really care whose definition of
> "privacy" is more accurate. It would be fantastic if we could get back
> to discussing actual technical details. TLS gives us reasonably good
> confidentiality of the data in motion over a TCP/IP connection. No, it
> doesn't provide privacy, but it addresses at least part of the overall
> problem and it's quite useful to adopt as the default option in
> probably 95% of our primary use cases. So Mark's proposal suggesting
> that we limit plaintext http/2 on port 80 to .local and rfc1918
> addresses appears completely reasonable so long as we take the
> additional step of defining a new default port for plaintext http/2
> everywhere else. If we can get agreement on that one technical point
> (as opposed to endless debating about what "privacy" really means)
> then we've made progress and can move on to the other important
> questions.
> 
> - James
> 

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Tuesday, 19 November 2013 17:12:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC