Re: ORIGIN - suggested changes

Stefan Eissing <> Thu, 02 February 2017 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30FF41293EC for <>; Thu, 2 Feb 2017 04:50:57 -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) header.b=JAb1Kfl8; dkim=pass (1024-bit key) header.b=Wf90Ixrx
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o8OqsAhtkQdN for <>; Thu, 2 Feb 2017 04:50:54 -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 01EEA1279EB for <>; Thu, 2 Feb 2017 04:50:53 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cZGmx-0003kp-HT for; Thu, 02 Feb 2017 12:46:59 +0000
Resent-Date: Thu, 02 Feb 2017 12:46:59 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cZGmt-0003jR-W0 for; Thu, 02 Feb 2017 12:46:56 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cZGmn-0000Mw-CN for; Thu, 02 Feb 2017 12:46:50 +0000
Received: by (Postfix, from userid 117) id 1802915A0AF5; Thu, 2 Feb 2017 13:46:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1486039582; bh=tGI15ikJ+AC0qNDOzMil1JzC891+SmnugVc/zQJvYXk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=JAb1Kfl8NCFdCpQiIU8NC5Rnnsa/5CZORJrESr84gLVl4lrWHKy4tUmoeZeH1Thdr L6VIut6NL1f9RLT6u13AdyST1hpFceibWyptLfuL8rvlDLu/aWwMpbCLoKUjtdONfr uO7VFGaKkMf4N3+7Mn4uA+CEK07M4jXelz13fIWo=
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 72EB715A073E; Thu, 2 Feb 2017 13:46:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1486039581; bh=tGI15ikJ+AC0qNDOzMil1JzC891+SmnugVc/zQJvYXk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Wf90IxrxtJJ4Do0oGx92CHKlBecYy06IysWYs+Nrj85P4YK5/4oZjCzqs0hqgyvXn bOjYxWZIa+MMRii11fHzIYUn/f2kkP6PRUFcra4aoGGRPZzc4h+kXqAWcpOsmngAGk l3uoZVaFuhyVXLt8WUrQwFvtBfpfoccP0HmpR9o8=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Stefan Eissing <>
In-Reply-To: <>
Date: Thu, 02 Feb 2017 13:46:21 +0100
Cc: Martin Thomson <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Mark Nottingham <>
X-Mailer: Apple Mail (2.3259)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: AWL=-1.147, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cZGmn-0000Mw-CN f6d61c9f9e858359efa88ebef972e3bd
Subject: Re: ORIGIN - suggested changes
Archived-At: <>
X-Mailing-List: <> archive/latest/33425
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> 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