Re: ORIGIN - suggested changes

Martin Thomson <> Wed, 01 February 2017 10:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CFC2129C65 for <>; Wed, 1 Feb 2017 02:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.719
X-Spam-Status: No, score=-9.719 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J2DCMfaZhbqq for <>; Wed, 1 Feb 2017 02:15:45 -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 46D8512996F for <>; Wed, 1 Feb 2017 02:15:44 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cYru0-0008Jl-Pm for; Wed, 01 Feb 2017 10:12:36 +0000
Resent-Date: Wed, 01 Feb 2017 10:12:36 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cYrtw-0008Iv-Cq for; Wed, 01 Feb 2017 10:12:32 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cYrtn-0000li-Gp for; Wed, 01 Feb 2017 10:12:27 +0000
Received: by with SMTP id k15so260065177qtg.3 for <>; Wed, 01 Feb 2017 02:12:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=umYNB4GdoZ08sncoFiCXwHGmMV0hIAbieTAqa5DZJBA=; b=kTomYFPs9/jet9PDd/LF0BSEkIpEJASXuManvQzGXTJW0BISaTnRryRjnE0tY0wdJp lHzyHqsZKwPEMQH5h9bNpHdOPF9X/MaukM0KwzQPtj5SUaFTvc38zsBXFp9au+iKFdai 22QrjgZbPRm401rf/+g0myN92NsZqsJUPcYHwP65btRUb6T2ElLggRXQwYvsFuIKWGNy nZHJCyj1+E0jcPxVppeQBofjnsvFAvYqSQE/90FnTGIqS1+e1c9vQhC2nAf4m8AO7WkP HCYUJ7rK5sGZZP6gnpmYmtUafrBOnEtEpufnTTQObiyG4+pmitRo+S2lUaGoxcFnw2CH v/0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=umYNB4GdoZ08sncoFiCXwHGmMV0hIAbieTAqa5DZJBA=; b=lcmfhRWG2OF4/NWGG3ORE4EzeU/jQ6W+NQ+kr9bNvGgJe4uCHGdijsAODcfbjcPUu+ 1c1i3XnRUHCzx0WeJ5CTlOuY3mfjoDowws9Jqk7wZJduORxBd8kyghzTwwbPqiv/7TxU kW1di8iuqDOjSCkxHwq1+X8Rpo3qd7wPyTV3pPRVqkPKZJ8b3SDz6bSjiggb5+HkGpdQ Mcga06FMkRae7OF2wwR+poSF4AiqxpqyGxD7HqpIGQN7hrHycXweOX+UNR75E30qVO6V HPJPtRurGafcgJLxbUzygPDLwGUfYe1ImFBgIIpImdpZzB2HjEkEMAglIC7WAR2SpX6x Y+gA==
X-Gm-Message-State: AIkVDXKVWLmIBcJIwkJER3jgViOEwniBslUz3zXTwqcrf1/xv5W4kP4hXIUDMlFSoxNcr6LYW/q+QfhYKgJoiw==
X-Received: by with SMTP id i88mr1945528qtb.143.1485943917552; Wed, 01 Feb 2017 02:11:57 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 1 Feb 2017 02:11:57 -0800 (PST)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Wed, 01 Feb 2017 21:11:57 +1100
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.7
X-W3C-Hub-Spam-Report: AWL=-0.223, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cYrtn-0000li-Gp 7989f821526e4455a10e22b2708bc3c1
Subject: Re: ORIGIN - suggested changes
Archived-At: <>
X-Mailing-List: <> archive/latest/33407
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

These seem like good changes in principle.  I've left a few comments
on the PR that say much the same as below...

On 1 February 2017 at 17:50, Mark Nottingham <> wrote:
>   - Removes the requirement for a supporting client to check DNS to determine if the server is authoritative, when ORIGIN is received

You should do something about http:// resources.  This means that this
is a perfect http:// hijacking mechanism.  I don't think that was the
intent.  I would prefer if this were limited to HTTPS, which at least
leaves certificate validation.

>   - Redefines the initial Origin Set as whatever SNI included (if anything).

If you do support this feature, the second change leads to having no
valid origins initially if you don't use SNI.  It also could be read
to prohibit coalescing as we do today.  Presumably the set is whatever
we have today until you see an ORIGIN frame.  You should probably say
something about that.

> Some people have also been talking about simplifying ORIGIN, e.g., by removing some of the set operations. I think we should talk about that on list first.

Let me put my stake in the ground.

The current design is just a little too complicated.  The ability to
clear the set and remove from the set is where a lot of that
complexity comes from.

Let's say that if you want to start over, then you really start over:
make a new connection in that case.  The need to remove is greatly
diminished by starting with a very small set.  If you do need to
cleave off an origin after previously advertising it, then ALTSVC is
available and much more graceful than anything this provides.  Removal
- as specified - is still subject to races and therefore violence,
since there is no acknowledgment.

That just leaves the frame being able to add origins to the set that a
client might consider using.  That's pretty easy to manage.  Anything
you have ever seen in an ORIGIN frame is a candidate.  Servers can add
to the set any time they like (likely in response to serving content
that references other origins), and clients can choose to forget
origins if the list ever gets too long for them to manage.

As a discretionary mechanism in this way, this could be a lightweight
feature that nicely complements ALTSVC.