Re: ORIGIN - suggested changes

[Patrick McManus <[e-mail]>]

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 <[e-mail]> wrote:

> Hey Stefan,
>
> > On 4 Feb 2017, at 12:22 am, Stefan Eissing <[e-mail]
> <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 <[e-mail]
> <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 <[e-mail]
> <javascript:;>> wrote:
> >>>
> >>>
> >>>> On 2 Feb 2017, at 12:23 pm, Martin Thomson <[e-mail]
> <javascript:;>> wrote:
> >>>>
> >>>> On 2 February 2017 at 10:12, Mark Nottingham <[e-mail]
> <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/
>
>
>