- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 3 Apr 2015 09:50:37 -0700
- To: Ryan Hamilton <rch@google.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 <rch@google.com> 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. > * 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 >
Received on Friday, 3 April 2015 16:51:04 UTC