- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 3 Apr 2015 09:51:47 -0700
- To: Ryan Hamilton <rch@google.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
https://github.com/httpwg/http-extensions/issues/62 On 3 April 2015 at 09:50, Martin Thomson <martin.thomson@gmail.com> 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. > > > > 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:52:14 UTC