RE: ORIGIN - suggested changes

Mike Bishop <> Thu, 02 February 2017 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D940129507 for <>; Thu, 2 Feb 2017 10:14:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.22
X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1AgPkYjb1ikf for <>; Thu, 2 Feb 2017 10:14:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F27B71294F1 for <>; Thu, 2 Feb 2017 10:14:42 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cZLrD-0003mg-1J for; Thu, 02 Feb 2017 18:11:43 +0000
Resent-Date: Thu, 02 Feb 2017 18:11:43 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cZLr5-0003lv-JF for; Thu, 02 Feb 2017 18:11:35 +0000
Received: from ([] by with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cZLqy-0004r7-TP for; Thu, 02 Feb 2017 18:11:30 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mrbaTblAP29cbn3oLK5tF3HpAfzkoEThlIbbrPS7mGc=; b=RR0p+n219Gpvkw21I2Yz5UmOAdd3oJxGG16U6TMKRtQKyajX5h1Eemuvs0srYrdeTklgj0w1U/3vsdyDdniOeoKGvRhk7ZiPrv5v1h2IrhHFs0OQN5yUy+PdkYfzExD+KGh7iiRJF7x0Zw1lT/drF+kEpXZG0+PTLB+DNWtdHZA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 2 Feb 2017 18:10:59 +0000
Received: from ([]) by ([]) with mapi id 15.01.0860.026; Thu, 2 Feb 2017 18:11:00 +0000
From: Mike Bishop <>
To: Stefan Eissing <>, Mark Nottingham <>
CC: Martin Thomson <>, HTTP Working Group <>
Thread-Topic: ORIGIN - suggested changes
Date: Thu, 02 Feb 2017 18:10:59 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 86792d19-9758-4a2c-66f5-08d44b96d795
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2706;
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:qfeAyji8oPohv6pX78sLZdVcuvVnt7Y94D1g48jFy7tfAOE/tXEu1tVloxHZNiVhYftxLPOTFGZJ7ROX74Hne/he5bPV8mPwBoRvxMGAF1JpvUYqhehRtgYs7Re/dEkGcMmNqMHLCsjvKnSc4bbv56mtYXehLLokFHhqn895OW9MMmxxl1VSzQpE4pXAQmQTBhT/8SHZmVzA5kTypclARDQ1/FfOA6rruuVQmKlx7v/a0Ui87WfLSnaRhZ5dkr4RkiUObvs9L5Hy7VHEXxvrt06GNtmo98+XNVb753nfZ8u2pNLN5OcHdSM/ZqpVH5pyUhsnZ/1TrhMwi1H8laE+hsktCgbt0fVaHGmWMsPhImT1da5+wUnPM2qrurUXgAhvEssv4AdRFtXlgX9z66RIW0vNKk3nBks6mqawmBHsD8urYu9aA7IbmiGshqadNfiQhF+jFkPRa4yI4tsih46PLkh3Gudkpsev+34zIPPP4BCIJMBCFsbBrII65jcj6p/Dz0Xjxh/w/DlWN5f11WMIkJPVdbh5DECjWiAQ/vNhaPH2yvSx2jE/P9+WnrKWadm5
x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay
x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148)(6042181); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706;
x-forefront-prvs: 02065A9E77
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(24454002)(199003)(189002)(377454003)(7736002)(39060400001)(3846002)(2906002)(50986999)(4326007)(86612001)(305945005)(2900100001)(74316002)(76176999)(3660700001)(122556002)(229853002)(53936002)(189998001)(6116002)(102836003)(97736004)(77096006)(38730400001)(6436002)(6506006)(5001770100001)(54356999)(8990500004)(106116001)(2950100002)(101416001)(105586002)(10090500001)(3280700002)(6306002)(10290500002)(93886004)(99286003)(15974865002)(81166006)(86362001)(81156014)(92566002)(25786008)(9686003)(55016002)(8936002)(54906002)(66066001)(8676002)(68736007)(33656002)(5660300001)(7696004)(106356001)(5005710100001)(18886075002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 18:10:59.6820 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: AWL=-1.996, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.143, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1cZLqy-0004r7-TP 35e328877da6aaf75a856e321cdf62eb
Subject: RE: ORIGIN - suggested changes
Archived-At: <>
X-Mailing-List: <> archive/latest/33427
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

That use of 1_1_REQUIRED surprises me; I would think 421 would be the appropriate response there, too, since the request needs to be made on a separate (but still HTTP/2) connection.

-----Original Message-----
From: Stefan Eissing [] 
Sent: Thursday, February 2, 2017 4:46 AM
To: Mark Nottingham <>
Cc: Martin Thomson <>; HTTP Working Group <>
Subject: Re: ORIGIN - suggested changes

> Am 02.02.2017 um 02:30 schrieb Mark Nottingham <>:
>> On 2 Feb 2017, at 12:23 pm, Martin Thomson <> wrote:
>> On 2 February 2017 at 10:12, Mark Nottingham <> wrote:
>>> I don't buy the argument that removal itself adds complexity. Implementations already need to remember what origins they received a 421 for, so they already have the concept of origin set removal.
>> Well, you just established why it might be unnecessary.  The gain 
>> here is in the client not sending a request to the wrong place.  But 
>> if this is rare enough, then that cost is probably bearable.
> Right, but the whole point of ORIGIN is to avoid those situations. 
>> The "everything except those" case doesn't concern me that much.
>> Iknow it's relatively common, but it is fairly rare that the set of 
>> origins that are used is not easily enumerable, or incrementally 
>> discoverable.
> Spoken like a true browser vendor :)
> It'd be good to get a bit more data here from server-side folks. Anyone share this concern? I note that Nick seems to be OK with it.

The feedback from Apache httpd users which have wildcard cert setups is: do not enable h2. 

From their PoV, they have a config running with HTTP/1.1 for years now, enabled h2 and all hell broke lose. Some sites work, some don't and that also depends on what your browser did before *). They do not want to change their setups, they expect h2 to just work or they will not use it. 

Currently, ORIGIN frame is not supported by httpd. My expectation is, once added, by default the server would send an empty ORIGIN frame, implying that the current connection should only be used for the SNI host. If I read the current spec correctly. (And btw. which browser plans to support it?)

Additionally, having configuration directives per virtual host where an admin can add other ORIGINs for connections to this very host, seems a good first step. My goal is to have the default "just work" in case of wildcard certs and require intentional configuration by the admin to optimize from there.

The feedback I am receiving on 421 response and HTTP_1_1_REQUIRED handling is not great. And it's difficult to debug for most people.

Cheers, Stefan

*) httpd replies with HTTP_1_1_REQUIRED when a stream encounters a TLS setup for a site that is not the same as the current connection.

> Cheers,
> --
> Mark Nottingham

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 M√ľnster