- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Sun, 5 Feb 2017 14:44:36 +0100
- 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>
- Message-ID: <CAOdDvNrcQGVyRaqF8462xVCrRw=x9nDwHRHOXq0or46iaRDBFg@mail.gmail.com>
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/ > > >
Received on Sunday, 5 February 2017 13:45:41 UTC