Subject: Re: Alt-Svc #62: proxies

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2015 11:05:36 +1000

On 1 Jun 2015, at 12:12 pm, Amos Jeffries <[email-masked]> wrote:
> 
> On 1/06/2015 1:01 p.m., Mark Nottingham wrote:
>> <https://github.com/httpwg/http-extensions/issues/62>
>> 
>> The current suggestion in the issue (made by me) is to add something like this to the spec:
>> 
>> "Clients configured to use a proxy SHOULD NOT use alternative services."
>> 
>> Comments?
> 
> +1.

Thinking about it a bit more, I'd actually modify that proposal slightly:

"A client configured to use a proxy for a given request SHOULD NOT send it to an alternative service, but instead use that proxy."

Make sense?

> The ALTSVC frame is explicitly hop-by-hop already. This helps to bring
> the HTTP/1 header behaviour in line with that.
> 
> A proxy will not be emitting ALTSVC frames. Nor should it be relaying
> Alt-Svc headers, unless its a legacy install treating them as unknown
> and relaying blindly.
> 
> I would hope for the HTTP/1 header to also be explicitly mentioned as
> hop-by-hop as well with a proxy / gateway requirement to SHOULD erase
> where possible on forwarding, or if received from an upstream proxy.

That seems reasonable, but I want to make sure we have agreement on that; there may be scenarios where a client would discover alternative services through a proxy, and then use them later (e.g., when the proxy isn't configured, or on a request that it's not configured for through something like proxy.pac). 

I've opened <https://github.com/httpwg/http-extensions/issues/83> to track.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Patrick McManus <[email-masked]>
Date: Mon, 8 Jun 2015 08:51:03 -0400

On Sun, Jun 7, 2015 at 9:05 PM, Mark Nottingham <[email-masked]> wrote:

> "A client configured to use a proxy for a given request SHOULD NOT send it
> to an alternative service, but instead use that proxy."
>
> Make sense?
>

yes.. because "clients configured to use a proxy" is not really a global
state for the client.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Jun 2015 09:54:00 +1000

Marked as editor-ready.

> On 8 Jun 2015, at 10:51 pm, Patrick McManus <[email-masked]> wrote:
> 
> 
> yes.. because "clients configured to use a proxy" is not really a global state for the client.
>

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 11 Jun 2015 08:54:21 -0700

​​
I'm not sure about this. Consider the case where a client is configured to
use proxy.example.com for all request. The client wants to request
https://www.service.com/. To do this, the browser connects to the proxy and
issues a CONNECT request, resulting in a TLS handshake and an HTTP/2
connection (via the proxy) to ww.service.com:443. Now, lets say that the
client wants to request https://mail.service.com. Previously,
mail.service.com advertised www.service.com:443 as an alternative service.
Should not the client be able to use the existing (tunneled through the
proxy) connection to www.service.com:443? The TLS connection *is*
end-to-end in this case (though the underlying TPC connection is not).

On Tue, Jun 9, 2015 at 4:54 PM, Mark Nottingham <[email-masked]> wrote:

> > "A client configured to use a proxy for a given request SHOULD NOT send
> it to an alternative service, but instead use that proxy."
> >
> > Make sense?
> >
> >

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Jun 2015 13:44:49 -0700

On 11 June 2015 at 08:54, Ryan Hamilton <[email-masked]> wrote:
> proxy) connection to www.service.com:443? The TLS connection *is* end-to-end
> in this case (though the underlying TPC connection is not).

Do we consider the proxy to be configured for the request or the connection?

I know that sophistry, but maybe it makes sense to invent that
distinction for this purpose.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 12 Jun 2015 12:07:04 +1200

> distinction for this purpose.

I dont think it matters.

The client UA has chosen to use www.service.com:443 and its configured
to use the proxy when sending requests to that authority. Whether it
re-uses the same connection or creates another CONNECT through the proxy
it should still be following the configured next-hop.

Thats usually the whole point of such configuration existing at all.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Jun 2015 13:38:33 +1000

> Thats usually the whole point of such configuration existing at all.

In that spirit:

"A client configured to use a proxy for a given request SHOULD NOT directly connect to an alternative service for it, but instead route it through that proxy."

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 11 Jun 2015 20:54:40 -0700

On Thu, Jun 11, 2015 at 8:38 PM, Mark Nottingham <[email-masked]> wrote:

> In that spirit:
>
> "A client configured to use a proxy for a given request SHOULD NOT
> directly connect to an alternative service for it, but instead route it
> through that proxy."
>

​Sounds good to me.​ Thanks!

---

From: Roland Zink <[email-masked]>
Date: Fri, 12 Jun 2015 10:32:22 +0200

> "A client configured to use a proxy for a given request SHOULD NOT directly connect to an alternative service for it, but instead route it through that proxy."
In that spirit the client should use the alternate service as URL when 
looking up which proxy to use in a PAC file. But what is the 
corresponding URL to use, e.g. should http://www.service.com:443/, 
https://www.service.com/ or 
http_opportunistic_security://www.service.com/ be used?

Regards,
Roland

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Jun 2015 09:30:06 -0700

On 12 June 2015 at 01:32, Roland Zink <[email-masked]> wrote:
> looking up which proxy to use in a PAC file. But what is the corresponding
> URL to use, e.g. should http://www.service.com:443/,
> https://www.service.com/ or http_opportunistic_security://www.service.com/
> be used?

Actually, I think not.  That means that proxies could become the
source of routing problems for users, but the right way to address
this is to have the proxy understand alternative services.  Or to
provide additional inputs, either to the CONNECT request or the query
to proxy.pac.

---

From: Roland Zink <[email-masked]>
Date: Fri, 12 Jun 2015 22:12:40 +0200

> provide additional inputs, either to the CONNECT request or the query
So the additional input is missing so far in the text and there are no 
plans to add them. I find it confusing if sometimes proxies should be 
used and sometimes not depending on how the proxy to use is configured.

Roland

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Jun 2015 13:38:45 -0700

On 12 June 2015 at 13:12, Roland Zink <[email-masked]> wrote:
> So the additional input is missing so far in the text and there are no plans
> to add them. I find it confusing if sometimes proxies should be used and
> sometimes not depending on how the proxy to use is configured.

Currently: "A client configured to use a proxy for a given request
SHOULD NOT directly connect to an alternative service for it, but
instead route it through that proxy."

I take that to mean that you would query proxy.pac with the request
URI.  That's limited, but no worse than what we have today.  If you
are motivated, you could fix the shortcoming, but the pragmatist in me
notices the efficacy of Mark's text in avoiding the need to specify
something that depends on a non-existent specification for proxy
discovery.

---

From: Roland Zink <[email-masked]>
Date: Fri, 12 Jun 2015 22:51:09 +0200

> something that depends on a non-existent specification for proxy
My concern is about a setup routing plain text http through a different 
proxy than TLS traffic. In this case this approach may fail. Don't know 
how often such an approach is used in practice.

Roland

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Jun 2015 13:56:13 -0700

On 12 June 2015 at 13:51, Roland Zink <[email-masked]> wrote:
> proxy than TLS traffic. In this case this approach may fail. Don't know how
> often such an approach is used in practice.

I see.  You might be right about that.  And it seems like a plausible
deployment arrangement.

That's a concern with opportunistic encryption more than anything
else.  Such a deployment might (might!) be able to suppress any
advertisements for secure alternatives.

On the positive side, the worst case here I can imagine isn't that
bad. The http:// proxy gets a connect request and has to drop it, so
that the alternative connection fails.