Re: Alt-Svc + Proxy Pac

[Ryan Hamilton <[e-mail]>]

On Fri, Apr 3, 2015 at 9:50 AM, Martin Thomson <[e-mail]>
wrote:

> Good question.
>
> I think that you put the original requested URL in and let the proxy
> worry about alt-svc compliance.
>
> The proxy is your overriding alternative.  That matches the logic in
> the case where the proxy.pac isn't present and you just have a
> hard-coded proxy that you send all requests to.
>
> Now, if the proxy.pac suggests that direct is acceptable, I think that
> makes it OK to (try to) use the alternative.  If you think of
> proxy.pac as a first level alternative selector, and alt-svc as a
> second-level one, I think that works.


​I'm happy to do this, but I fear it's going to have problems. Let me lay
out an example and if everyone agrees to send in the request URL, I'm fine
with that.

Consider the following scenario. There are two servers, internal.example.com
and external.example.com. Inside the enterprise access to resources outside
the firewall must go through a proxy, whereas resource inside the firewall
can go direct. That would lead to a .pac file like:

function FindProxyForURL(url, host) {​

​  if (host == "internal.example.com") {
    return "DIRECT";
  }
  return "PROXY proxy.example.com";
}​


If Alt-Svc for internal says, "Alt-Svc: h2="external.exmple.com:443", then
​the proxy will say, "Sure, go direct to http://internal.example.com/" but
then the browser will connect to external.example.com:443 and will avoid
the proxy and the request will hang. This seems a bit unfortunate, but it's
not clear that the alternative is much better, so I'm happy to do this, if
that's the consensus of the group.

Cheers,

Ryan