Re: Alt-Svc #62: proxies

On 12 Jun 2015, at 10:07 am, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 
> On 12/06/2015 8:44 a.m., Martin Thomson wrote:
>> On 11 June 2015 at 08:54, Ryan Hamilton <rch@google.com> wrote:
>>> 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).
>> 
>> 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.
> 
> 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.

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."


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

Received on Friday, 12 June 2015 03:39:10 UTC