- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 26 Oct 2012 14:28:09 +1300
- To: ietf-http-wg@w3.org
On 26/10/2012 10:34 a.m., Adrien W. de Croy wrote: > > ------ Original Message ------ > From: "Yoav Nir" <ynir@checkpoint.com> > To: "Patrick McManus" <pmcmanus@mozilla.com> > Cc: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>;"Mark > Nottingham" <mnot@mnot.net>;"Willy Tarreau" <w@1wt.eu>;"Amos Jeffries" > <squid3@treenet.co.nz>;"ietf-http-wg@w3.org" <ietf-http-wg@w3.org> > Sent: 26/10/2012 2:21:46 a.m. > Subject: Re: #385: HTTP2 Upgrade / Negotiation >> On Oct 25, 2012, at 3:01 PM, Patrick McManus wrote: >> >> >>> >>> I know this has been said before by the Chrome team, but I too am >>> starting to see websocket bugs pile up due to transparent proxies >>> that don't speak upgrade and explicit proxies that don't let you >>> tunnel to port 80 as configured. >>> >> >> >> Transparent proxies should learn about Upgrade: and either support >> websockets/http2 or remove the header. Hopefully they will have done >> this by the time HTTP/2.0 over port 80 is actually deployed. >> >> >>> >>> (bluecoat and MS ISA/TMG are the most common I hear about). ws:// >>> hasn't been very successful in those environments but wss:// has >>> been. Good thing that in the websockets world there aren't a lot of >>> legacy urls to worry about - not true for http :( >>> >>> For http2, I don't think it is enough to just fail fast to http/1 >>> when for most cases we could get those users speaking HTTP/2 over >>> tls on 443. A mechanism like Alternate-Protocol accomplishes that >>> and I think that is a more important property than upgrading in band >>> (which is admittedly nice!). >>> >> >> >> So rather than go to HTTP/1.1 you'd prefer going to TLS with an >> anonymous ciphersuite? I don't think that would help much, as the >> transparent proxies that also MitM SSL are getting ever more popular. >> >> >>> >>> As for caching successful upgrades or successful A-P's they pretty >>> much have the same set of tradeoffs. >>> >> >> >> Yes, but I don't think it's all that bad. Browsers and operating >> systems have some feeling of location, which changes when any of your >> IP addresses change, or your routing table changes, or the >> configuration of the proxy or DNS servers changes. Browsers notice >> these things so that they can quickly re-establish connections, >> re-query the DNS, and reload pages that had some failure. If you >> have this event also invalidate the cache, so that you go through the >> Upgrade handshake again, you should usually not have a case where a >> proxy has suddenly got in your path and won't let you use HTTP/2 over >> TCP port 80 any more. >> > > On this note, I think it would be really useful if there could be some > machine-readable way to query a proxy for HTTP-related capabilities. > If that were part of 2.0, then failure to respond appropriately to > such a query would in itself be an indication of lack of support for 2.0. > > The client could do this test whenever it became aware of using a new > proxy, e.g. before anyone types a URI or clicks a shortcut. So by the > time the first user request is made, the client should know all it > needs to know about the proxy. We should at least be able to solve > that part of the problem. You mean "OPTIONS * HTTP/..." ? Amos
Received on Friday, 26 October 2012 01:28:44 UTC