Subject: Alt-Svc + Proxy Pac

From: Ryan Hamilton <[email-masked]>
Date: Fri, 3 Apr 2015 07:35:03 -0700

Howdy Folks,

I'm curious how Alt-Svc is expect to work with Proxy PAC files. Consider
the scenario where http://www.example.com/ has an Alt-Svc that specified
http/2 on mail.example.com:443. When the browser decides to make an http/2
(over TLS) connection to mail.example.com, on behalf of
http://www.example.com, what URL and host should the browser pass to the
PAC file's FindProxyForURL() method?

I can argue both cases.

* It should pass in the requested url (http://www.example.com/) because
that is the URL being requested. There is no other URL.
* It should pass in a pseudo url (https://mail.exmaple.com/) because, for
example, access to mail.example.com may well requires use of a proxy to
access. By passing in the request URL, the PAC file does not have the
opportunity to send the connection to the correct proxy.

Thoughts?

Cheers,

Ryan

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Apr 2015 09:50:37 -0700

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.

On 3 April 2015 at 07:35, Ryan Hamilton <[email-masked]> wrote:
> Howdy Folks,
>
> I'm curious how Alt-Svc is expect to work with Proxy PAC files. Consider the
> scenario where http://www.example.com/ has an Alt-Svc that specified http/2
> on mail.example.com:443. When the browser decides to make an http/2 (over
> TLS) connection to mail.example.com, on behalf of http://www.example.com,
> what URL and host should the browser pass to the PAC file's
> FindProxyForURL() method?
>
> I can argue both cases.
>
> * It should pass in the requested url (http://www.example.com/) because that
> is the URL being requested. There is no other URL.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Apr 2015 09:51:47 -0700

https://github.com/httpwg/http-extensions/issues/62

---

From: Francesco Chemolli <[email-masked]>
Date: Fri, 3 Apr 2015 19:13:24 +0200

> opportunity to send the connection to the correct proxy.

Hi Ryan,
  good point.
  I favor the second option, as in current corporate environments (the
main users of pacfiles, I expect) different destinations may require
very different forwarding paths, so it's best to have the earliest
possible decision point.
I also suggest considering a third, longer-term option: seeking an
agreement among impementors about modernizing (and possibly
standardizing) the pac-file API.

-- 
    Francesco Chemolli
    Squid Developer

---

From: Patrick McManus <[email-masked]>
Date: Fri, 3 Apr 2015 14:03:09 -0400

I agree with martin's suggested resolution.

fwiw the original netscape documentation says that the host argument is the
host extracted from the url for convenience (what else could it say?). I
think making existing pacs do indeterminate things based on which argument
they are looking at is a mistake.

separately - there has been some talk about standardizing modern pac - One
thing we could do in that space is make the list of alternatives available
to the PAC file though a separate variable, argument, or helper function.
The PAC is really about routing afterall. It could not only select a proxy
with that information, it could also implement alternate selection (through
some new return mechanism) and return DIRECT.

-P

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 3 Apr 2015 13:50:08 -0700

> 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

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 3 Apr 2015 13:55:02 -0700

On Fri, Apr 3, 2015 at 11:03 AM, Patrick McManus <[email-masked]>
wrote:

> fwiw the original netscape documentation says that the host argument is
> the host extracted from the url for convenience (what else could it say?).
> I think making existing pacs do indeterminate things based on which
> argument they are looking at is a mistake.
>

​Something like that would be great. If there are several alternative
available for a given request, a browser probably won't attempt to connect
to all of them at once, instead it will likely pick one and connect to
that. This makes me think that we'd want an method like:

function FindProxyForUrl(url, alternative)

​Where |alternative|​ is the alternative service being used. For example:

FindProxyForUrl("http://internal.example.com",

                {"h2", "external.example.com", 443});

FindProxyForUrl("https://external.example.com",
                {"QUIC", "external.example.com", 443});

​Or some such...

Cheers,

Ryan
​

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 3 Apr 2015 13:57:25 -0700

> second-level one, I think that works.

​Actually, reading this more closely, I think you're suggesting that if the
.pac file suggests using a proxy then Alt-Svc should be ignored. Am I
reading that right? If so, that is surprising. Consider a .pac which sends
all requests through the proxy. If two hosts are alternatives for each
other and we already have an h2 connection to one (via the proxy) it would
be great to be able to use that connection​

​for the other host. I hope the spec permits this. If not, I think we
should discuss it more :>

Cheers,

Ryan​

---

From: Patrick McManus <[email-masked]>
Date: Fri, 3 Apr 2015 17:04:16 -0400

On Fri, Apr 3, 2015 at 4:50 PM, Ryan Hamilton <[email-masked]> wrote:

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

The browser is supposed to validate the alternate service (among other
things by checking that it has a cert valid for the origin) before using it
and fall back if it is unavailable. So it seems that
external.example.com:443 could not be validated in your example and if
perhaps that validation were stale, it should get automagically cleaned up.

I would be very cautious about ever changing url based on alt-svc.. alt-svc
does not change origins or urls. If it did, it would get very hard to
reason about. but supplying the alt information explicitly seems a lot more
interesting. Somebody should really write up a I-D for a modern PAC (that
could be me, but realistically a lot of other things would have to come off
the todo list first.)

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 3 Apr 2015 14:17:56 -0700

On Fri, Apr 3, 2015 at 2:04 PM, Patrick McManus <[email-masked]>
wrote:

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

​Agreed! When I said, "the request will hang", I meant to say, "the
connection will hang". You're totally right that this won't be a user
facing problem.​

​We won't use the alternative-service but it's not the end of the world.​
​

> interesting.

​Agreed.​

> Somebody should really write up a I-D for a modern PAC (that could be me,
> but realistically a lot of other things would have to come off the todo
> list first.)
>

​SGTM. Especially the part about you doing the work :>​

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Apr 2015 17:33:21 -0700

On 3 April 2015 at 13:50, Ryan Hamilton <[email-masked]> wrote:
> 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

I think that's what you get here.  It's an alternative, so the only
consequence should be that you don't use external.example.com.