Re: Sec-Scheme request header?
Amos Jeffries <squid3@treenet.co.nz> Thu, 14 April 2016 10:30 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0248212D6A0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 03:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.917
X-Spam-Level:
X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 c-WIa8WOnJNT for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 03:30:31 -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 A2FDC12D739 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 14 Apr 2016 03:30:31 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aqeTA-0003Ig-IH for ietf-http-wg-dist@listhub.w3.org; Thu, 14 Apr 2016 10:25:52 +0000
Resent-Date: Thu, 14 Apr 2016 10:25:52 +0000
Resent-Message-Id: <E1aqeTA-0003Ig-IH@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1aqeT7-0003Hz-3x for ietf-http-wg@listhub.w3.org; Thu, 14 Apr 2016 10:25:49 +0000
Received: from [121.99.228.82] (helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1aqeT5-0005mZ-HP for ietf-http-wg@w3.org; Thu, 14 Apr 2016 10:25:48 +0000
Received: from [192.168.20.251] (unknown [121.98.40.13]) by treenet.co.nz (Postfix) with ESMTP id 04E10E6F6C for <ietf-http-wg@w3.org>; Thu, 14 Apr 2016 22:25:14 +1200 (NZST)
To: ietf-http-wg@w3.org
References: <ED1304AC-126B-486B-A58D-81D24C8F5C06@mnot.net> <CAKXHy=f=499HWYurEsTodjrJr6rR7DBkcFiVwmJGE0ogYFPAaQ@mail.gmail.com> <CAOdDvNrZuDHBLcMeKNhCMewi1zKOAnUt-CY9Cdh4vgi-CjcVAg@mail.gmail.com> <CABkgnnUxh=Anv3HjCMo9nhggmmTz8G+Mc2WHLtugBrdb1Jppzw@mail.gmail.com> <B66FB746-B2D0-4106-91AC-B4E0995BE75A@mnot.net> <CAKXHy=e8yD=Ask4kR6zhH9-1YSOqJXexb1XaRjgTp0aMXTUiqw@mail.gmail.com> <A9541032-39B5-48CE-86B7-A04A7C84E75D@mnot.net> <CAKXHy=eY3vLogKBCPHvdXZds+mh_+2ZF-OX=HcNzrRUoi6a8PQ@mail.gmail.com>
From: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <570F7005.7090704@treenet.co.nz>
Date: Thu, 14 Apr 2016 22:25:09 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAKXHy=eY3vLogKBCPHvdXZds+mh_+2ZF-OX=HcNzrRUoi6a8PQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-1.178, BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1aqeT5-0005mZ-HP f7a234bbc163e6411b7502a5dea2e295
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Sec-Scheme request header?
Archived-At: <http://www.w3.org/mid/570F7005.7090704@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31456
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
On 14/04/2016 8:06 p.m., Mike West wrote: > On Thu, Apr 14, 2016 at 10:00 AM, Mark Nottingham wrote: > >> This is something that would be really useful for disambiguating things in >> cases where the same server-side code is handling both HTTP and HTTPS URLs. >> > > I think I'd prefer to encourage folks to treat HTTP and HTTPS as "the same" > with regard to the resource which is being universally {identified, > located}. I freely admit, however, that I'm not at all familiar with what > developers do with backend servers and proxies and CDNs, so I'm sure there > are solid use cases I'm missing. Could you point me to some? > > -mike > Taking the abstract view we have several cases: 1) anything talking to legacy install 1.1 servers - nothing helps here. old software ignores new features. - when its upgraded the new software will become h2-enabled right? which makes it move to another case. 2) h2 enabled server/gateway talking to legacy install 1.1 client - nothing helps here. - thats the clients fault, and when upgraded will become h2-enabled which is a higher numbered case. 3) h2 client talking to h2 server. - just use :scheme. Wins all around. 4) h2 enabled client/server endpoints talking over 1.1 middleware - Scheme: might help. BUT actually using absolute-URL for the request-target would help more. Since it helps ensure the scheme + host are treated as a pair and not getting separated or confused. BUT, lets be honest explicit-proxy middleware is already using absolute-URL so case #4 is only a problem when interception MITM are present. So the radical and politically incorrect proposal: begin a campaign to get clients to just use absolute-URL over 1.1 regardless of the connection type. Port 80, port 443, taking to an explicit proxy - no more special casing just send absolute-URL. In its favour this campaign can be done with just a consensus and small amount of conspiracy to actually implement by us WG participants. It does not require full h2 implementation to participate, and there is a slight/rare chance it might actually do something useful for case #1. And it simplifies and should speed up processing in both browsers and the annoyingly slow MITM middleware. On the downside we hit an (unkown?) amount of servers not complying with the RFC requirement to accept absolute-URL. And other weirdness, like ignoring it in favour of Host (which could be dropped BTW, more savings!). Amos
- Sec-Scheme request header? Mark Nottingham
- Re: Sec-Scheme request header? Mike West
- Re: Sec-Scheme request header? Patrick McManus
- Re: Sec-Scheme request header? Martin Thomson
- Re: Sec-Scheme request header? Mark Nottingham
- Re: Sec-Scheme request header? Mike West
- Re: Sec-Scheme request header? Mark Nottingham
- Re: Sec-Scheme request header? Mike West
- Re: Sec-Scheme request header? Amos Jeffries