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

HTTPS, proxy environment variables and non-CONNECT access

From: Robert Collins <robertc@squid-cache.org>
Date: Tue, 16 Jul 2013 18:08:31 +1200
Message-ID: <CAJ3HoZ3ZuBwAZWrsgrZkoBejeH0t0uJRWAdiy1eKKbQwM3xx5g@mail.gmail.com>
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.

Received on Tuesday, 16 July 2013 06:08:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC