Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9B1ACE77 for ; Fri, 3 Apr 2015 11:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id facFrdm6zZ1z for ; Fri, 3 Apr 2015 11:07:25 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABA41ACE8D for ; Fri, 3 Apr 2015 11:07:25 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from ) id 1Ye5wQ-00034c-Pg for ietf-http-wg-dist@listhub.w3.org; Fri, 03 Apr 2015 18:03:38 +0000 Resent-Date: Fri, 03 Apr 2015 18:03:38 +0000 Resent-Message-Id: Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from ) id 1Ye5wM-00033I-Tq for ietf-http-wg@listhub.w3.org; Fri, 03 Apr 2015 18:03:34 +0000 Received: from li629-102.members.linode.com ([192.155.95.102] helo=linode64.ducksong.com) by maggie.w3.org with esmtp (Exim 4.80) (envelope-from ) id 1Ye5wL-0004kd-T7 for ietf-http-wg@w3.org; Fri, 03 Apr 2015 18:03:34 +0000 Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id B66B33A05C for ; Fri, 3 Apr 2015 14:03:09 -0400 (EDT) Received: by qcbii10 with SMTP id ii10so71068584qcb.2 for ; Fri, 03 Apr 2015 11:03:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.107.165 with SMTP id h34mr4025238qgf.71.1428084189408; Fri, 03 Apr 2015 11:03:09 -0700 (PDT) Received: by 10.140.94.7 with HTTP; Fri, 3 Apr 2015 11:03:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Apr 2015 14:03:09 -0400 Message-ID: From: Patrick McManus To: Martin Thomson Cc: Ryan Hamilton , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary=001a1139594ed1b7450512d5c2b5 Received-SPF: none client-ip=192.155.95.102; envelope-from=mcmanus@ducksong.com; helo=linode64.ducksong.com X-W3C-Hub-Spam-Status: No, score=-4.2 X-W3C-Hub-Spam-Report: AWL=-2.167, HTML_MESSAGE=0.001, W3C_AA=-1, W3C_WL=-1 X-W3C-Scan-Sig: maggie.w3.org 1Ye5wL-0004kd-T7 1bd0b28e395cbcf407f2428247d57609 X-Original-To: ietf-http-wg@w3.org Subject: Re: Alt-Svc + Proxy Pac Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/29236 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --001a1139594ed1b7450512d5c2b5 Content-Type: text/plain; charset=UTF-8 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 On Fri, Apr 3, 2015 at 12:51 PM, Martin Thomson wrote: > https://github.com/httpwg/http-extensions/issues/62 > > On 3 April 2015 at 09:50, Martin Thomson 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 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 > >> > > --001a1139594ed1b7450512d5c2b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with martin's suggested resolut= ion.

fwiw the original netscape documentation says that t= he host argument is the host extracted from the url for convenience (what e= lse could it say?). I think making existing pacs do indeterminate things ba= sed 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 avail= able to the PAC file though a separate variable, argument, or helper functi= on. The PAC is really about routing afterall. It could not only select a pr= oxy with that information, it could also implement alternate selection (thr= ough some new return mechanism) and return DIRECT.

-P


On Fri, Apr 3, 2015 at 12:51 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
= 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.=C2=A0 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.=C2=A0 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
>>


--001a1139594ed1b7450512d5c2b5--