Re: ORIGIN - suggested changes

Stefan Eissing <> Thu, 02 February 2017 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2EE21294FD for <>; Thu, 2 Feb 2017 10:49:04 -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=f4FpjPwn; dkim=pass (1024-bit key) header.b=suHXythK
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1G23QjXWdpB7 for <>; Thu, 2 Feb 2017 10:49:03 -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 49A53129473 for <>; Thu, 2 Feb 2017 10:49:03 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cZMOi-0003RY-Dq for; Thu, 02 Feb 2017 18:46:20 +0000
Resent-Date: Thu, 02 Feb 2017 18:46:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cZMOg-0003PP-0q for; Thu, 02 Feb 2017 18:46:18 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cZMO6-0002rX-4Y for; Thu, 02 Feb 2017 18:46:12 +0000
Received: by (Postfix, from userid 117) id 9A78E15A0E47; Thu, 2 Feb 2017 19:45:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1486061114; bh=fpFXWqX9egN1FdKRIo4vUytvEsEOmMYBUvcgX1n89i8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=f4FpjPwny68KwyGWq6QtoRwzJZqDC8bXuMGT8NevmswbSYYowz03zjTLy/eCPHLr6 Uwf9BDmRNOgUb7qWfEGD3nWEcJF7Ictn+w91Uw7Ib1rVNv8e/Yh+7sMi8YQEmLeRNr 9Pt8eFPxI6fE2sVQ1mGmQZk5GBGKC8J1K45YospY=
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 3AB5415A03A1; Thu, 2 Feb 2017 19:45:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1486061113; bh=fpFXWqX9egN1FdKRIo4vUytvEsEOmMYBUvcgX1n89i8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=suHXythKra1ZPLWz/DADdfE4Tq0rFHW6TKqOHT5klXB7dckrr8azMh9M3EJMgcSmM g8+w2wAAwOIX2rLovXf3JU4of+qY1h2Piv0BIjxTHqlbeUeRkVsGUf7BS+dJsb8geK NAMTx6e+c4tJvwaFxAh9eH/gOMSPgCFaZKjam5NI=
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 19:45:12 +0100
Cc: Mark Nottingham <>, Martin Thomson <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Mike Bishop <>
X-Mailer: Apple Mail (2.3259)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=0.0
X-W3C-Scan-Sig: 1cZMO6-0002rX-4Y ed9a701f7aa54bcc6d5383e68ada5dc0
Subject: Re: ORIGIN - suggested changes
Archived-At: <>
X-Mailing-List: <> archive/latest/33428
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

You are correct that the most frequent case is a 421 answer. The 1_1_REQUIRED is returned when the TLS layer detects a renegotiate attempt. Often, these are triggered by client certs, but some people seem to also require other ciphers in certain locations (don't ask my why).

I am not saying that all the confusion stems from HTTP/2. It's merely that the TLS+HTTP/1.1 combination made things possible that, at the moment, are not possible with h2. I know your and other peoples efforts to improve this. However until then, I'd like to offer a "safe" default in the server. I hope ORIGIN will allow me to do that.

> Am 02.02.2017 um 19:10 schrieb Mike Bishop <>:
> 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

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster