Re: ORIGIN - suggested changes

[Stefan Eissing <[e-mail]>]

> Am 05.02.2017 um 14:44 schrieb 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.)

I'm fine with this alternate way of handling changes. GOAWAY will probably be my choice, avoiding complexity.

Will track my implementation efforts here (https://github.com/icing/mod_h2/issues/96) for anyone interested or wanting to give feedback.

Cheers, Stefan

> -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]> 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]>:
> >>
> >> 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]> wrote:
> >>>
> >>>
> >>>> On 2 Feb 2017, at 12:23 pm, Martin Thomson <[e-mail]> wrote:
> >>>>
> >>>> On 2 February 2017 at 10:12, Mark Nottingham <[e-mail]> 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/

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de