Re: ORIGIN - suggested changes

Patrick McManus <mcmanus@ducksong.com> Sun, 05 February 2017 13:49 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 AED71129410 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 5 Feb 2017 05:49:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.42
X-Spam-Level:
X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sendgrid.me
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 duRLhsDsAoky for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 5 Feb 2017 05:48:59 -0800 (PST)
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 49B0812896F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 5 Feb 2017 05:48:58 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1caN8V-0007q9-UA for ietf-http-wg-dist@listhub.w3.org; Sun, 05 Feb 2017 13:45:47 +0000
Resent-Date: Sun, 05 Feb 2017 13:45:47 +0000
Resent-Message-Id: <E1caN8V-0007q9-UA@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1caN8P-0007pL-1r for ietf-http-wg@listhub.w3.org; Sun, 05 Feb 2017 13:45:41 +0000
Received: from o1.7nn.fshared.sendgrid.net ([167.89.55.65]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1caN7p-0002zm-3c for ietf-http-wg@w3.org; Sun, 05 Feb 2017 13:45:35 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.me; h=mime-version:in-reply-to:references:from:subject:to:cc:content-type; s=smtpapi; bh=4kQjSLJLGsWNWVjOCVmXMgJ45F0=; b=MilkOvUB7lzJE+pHvQ N0cSs/V4i6CxSzyuQVvgJphK4Ubswv8ctJTTgjWfo59x34VjZX+RnhD0npCNr2AX O1lqZm3Gp36nmKBfRM4ZjjCQqAhK4wT+dUBDM7SjKLpF/0TrUAZqPa47vvkWRWNP iKcvutpbHFx5MWWyrzFsDZs6E=
Received: by filter0627p1mdw1.sendgrid.net with SMTP id filter0627p1mdw1-8712-58972C44-4E 2017-02-05 13:44:36.999236518 +0000 UTC
Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com [209.85.216.176]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id 9awahWrJTA2IAaSWaJr-sg for <ietf-http-wg@w3.org>; Sun, 05 Feb 2017 13:44:37.228 +0000 (UTC)
Received: by mail-qt0-f176.google.com with SMTP id x49so84872033qtc.2 for <ietf-http-wg@w3.org>; Sun, 05 Feb 2017 05:44:37 -0800 (PST)
X-Gm-Message-State: AMke39n/1LbnhOskds5YVpnF4I9t6S2svNrQMr1OGn0oQbHf3PgBe0MPdCrr6uc0x5wuJd+wQWjwgOuB4dP2UA==
X-Received: by 10.200.51.6 with SMTP id t6mr5055424qta.75.1486302276876; Sun, 05 Feb 2017 05:44:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.162.65 with HTTP; Sun, 5 Feb 2017 05:44:36 -0800 (PST)
In-Reply-To: <4E2307AE-721B-4F4F-9B72-5E661273C704@mnot.net>
References: <C3CCA267-F5B5-4827-AC27-9853BDADACDE@mnot.net> <CABkgnnWaN6Kaq28=a+At_YQcZmG_o0-VRMAWBABzdLz-RBxxPA@mail.gmail.com> <5D2EB826-204B-44FC-AB42-B0BBECF9AE62@mnot.net> <CABkgnnX26M2P1Kp-PxPDzREZGp0nGfuJubgTqrs9Hr7n8ttqdA@mail.gmail.com> <373E9285-B023-4D42-A749-368649E34252@mnot.net> <2DAB7A8F-2614-4448-8DA9-6967E6E3BD06@mnot.net> <933D3A82-615A-4C75-8F3D-8298E8C6969E@greenbytes.de> <4E2307AE-721B-4F4F-9B72-5E661273C704@mnot.net>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Sun, 5 Feb 2017 14:44:36 +0100
X-Gmail-Original-Message-ID: <CAOdDvNrcQGVyRaqF8462xVCrRw=x9nDwHRHOXq0or46iaRDBFg@mail.gmail.com>
Message-ID: <CAOdDvNrcQGVyRaqF8462xVCrRw=x9nDwHRHOXq0or46iaRDBFg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>, "Nygren, Erik" <nygren@akamai.com>
Content-Type: multipart/alternative; boundary=001a1145bf903e23800547c8b718
X-SG-EID: YLWet4rakcOTMHWvPPwWbcsiUJbN1FCn0PHYd/Uujh72DI/m8IYPKwfnub6n1pSxZHL5fiFeMszY22 AjLiGe4ekZ6J+8JwuB8z8qNNa3K3lVSucQw5qVN+HvbBPsY0L41wT48OnQj3cARKc6rmA6en0iQ0ai tRRi09APZA7j55i8vQ40fo49uZl7Pegj+eZvfD25Ib/ZcsXYR3MEQ1OQWIg5EQKUvZsFPFGtBBng7a I=
Received-SPF: pass client-ip=167.89.55.65; envelope-from=bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net; helo=o1.7nn.fshared.sendgrid.net
X-W3C-Hub-Spam-Status: No, score=-1.4
X-W3C-Hub-Spam-Report: RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, TIME_LIMIT_EXCEEDED=0
X-W3C-Scan-Sig: titan.w3.org 1caN7p-0002zm-3c 7f6187d8eb96ee4a90d6d8b6b9a4d945
X-Original-To: ietf-http-wg@w3.org
Subject: Re: ORIGIN - suggested changes
Archived-At: <http://www.w3.org/mid/CAOdDvNrcQGVyRaqF8462xVCrRw=x9nDwHRHOXq0or46iaRDBFg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33445
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>

I feel that ORIGIN has succeeded in getting unparked by being very attuned
to specific use cases.. first it turned into a "sni only" settings bit, and
now (based on use case) an explicit declarative opt-in. to me - that feels
right.

I view this as declarative - if your configuration changes GOAWAY or
Alt-Svc are probably better ways to manage it. I spitballed that we should
only allow 1 ORIGIN frame, but that basically isn't plausible due to size
limitations, I don't really expect it to be used to dribble updates over
time. (but normatively enforcing that would require some kind of
CONTINUATION world I hope nobody wants to entertain.)

-P


On Saturday, February 4, 2017, Mark Nottingham <mnot@mnot.net> wrote:

> Hey Stefan,
>
> > On 4 Feb 2017, at 12:22 am, Stefan Eissing <stefan.eissing@greenbytes.de
> <javascript:;>> wrote:
> >
> > Looks good to me.
> >
> > *But* I think I would be good to have an ORIGIN frame that says: please
> revert your ORIGIN set back to undefined for this connection (and erase all
> 421 derived information).
> >
> > This should be less complex than individual removes and provide for
> changes on very long lived connections.
>
> I hear what you're saying, but so far the strongest blocker for this spec
> has been complexity, so I'd like to hear what others (especially
> implementers on the client side, where most of the work is) think.
>
>
>
>
> >
> > -Stefan
> >
> >> Am 03.02.2017 um 01:43 schrieb Mark Nottingham <mnot@mnot.net
> <javascript:;>>:
> >>
> >> I've done some more updating:
> >> https://github.com/httpwg/http-extensions/pull/285
> >>
> >> At this point, the diff isn't too helpful, so see attached.
> >>
> >> Changes include:
> >>
> >> 1. Removing set manipulation flags
> >> 2. Reserving some flags for future backwards-incompatible extensions
> (which makes me feel a bit better about #1)
> >> 3. Note impact upon Server Push
> >> 4. Added IANA Considerations and Operational Considerations
> >> 5. Lots of clarifications
> >>
> >> Feedback welcome, as always.
> >>
> >>
> >> <draft-ietf-httpbis-origin-frame.html>
> >>
> >>
> >>> On 2 Feb 2017, at 12:30 pm, Mark Nottingham <mnot@mnot.net
> <javascript:;>> wrote:
> >>>
> >>>
> >>>> On 2 Feb 2017, at 12:23 pm, Martin Thomson <martin.thomson@gmail.com
> <javascript:;>> wrote:
> >>>>
> >>>> On 2 February 2017 at 10:12, Mark Nottingham <mnot@mnot.net
> <javascript:;>> 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.
> >>>
> >>> Cheers,
> >>>
> >>> --
> >>> Mark Nottingham   https://www.mnot.net/
> >>>
> >>>
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >>
> >
> > Stefan Eissing
> >
> > <green/>bytes GmbH
> > Hafenstrasse 16
> > 48155 M√ľnster
> > www.greenbytes.de
> >
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>