- From: Robert Collins <robertc@squid-cache.org>
- Date: Tue, 16 Jul 2013 18:08:31 +1200
- To: HTTP Working Group <ietf-http-wg@w3.org>
So [fairly recently] squid and other proxies can retrieve resources over HTTPS. However user agents generally don't take advantage of this, instead using CONNECT, to do end to end encryption. One of the ramifications of saying we'd like to be able to do explicit recommendations for a proxy [which I know is a longer term thing] is that clients need to be /able/ to do HTTPS via their proxy - e.g. client <- https -> proxy <- https -> origin, and/or client <- http -> proxy <- https -> origin. Today, for unix UAs, https_proxy when set results in a connection to the named proxy and then a CONNECT verb. I'd like to start getting UAs to stop doing the CONNECT verb. but redefining the behaviour of https_proxy seems super risky. So - looking for input (and here is as good a place as any, so please excuse the technically off-topic thread) on how to signal that. We could add a new variable to control the behaviour of https_proxy : e.g. https_proxy_mode=[connect|native] with unrecognised or absent values treated as 'connect'. Or we could add a new variable e.g. https_trusted_proxy=<URI> and have that take priority. Does anyone have: - a better place to raise this - or thoughts on this? I'm sure that implementing this will start to raise issues like 'how do we signal client certificates indirectly' and so on, which *will* be HTTP protocol issues, but one step at a time. -Rob
Received on Tuesday, 16 July 2013 06:08:59 UTC