Re: Working Group Last Call The ORIGIN HTTP/2 Frame

Yes, my suggestion was to add a client field to the initial settings frame.
However, this suggestion is orthogonal to the concerns raised on this
thread. I agree with the conclusions of this thread that a settings option
sent from the server to indicate which model is being used is not very
useful. I support closing the PR.

If a client-sent settings frame that can be used to
(a) indicate support for ORIGIN, and
(b) indicate a max origin set size
is something that people consider valuable, it should be probably be raised
in a different thread.

Nick

On Tue, Oct 3, 2017 at 12:09 AM Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:

> To track back to that, Nick suggested a new frame called ORIGIN_SUPPORT
> but reading between the lines this could be a setting like
> SETTINGS_ENABLE_PUSH. I don't have a strong opinion and don't have a full
> handle on the concerns raised about a server-sent setting.
>
> I'm not sure if Nick was suggesting such a thing could be set on
> connection initiation only, or if it could be changed during runtime.
>
> The latest draft added a security consideration for the unbounded origin
> set, perhaps a client-sent SETTINGS_MAX_ORIGIN_SET_SIZE could be used to
> provide two functions - bound the origin set size, or disable origin
> altogether (size 0). Exceeding such a boundary violation would result in a
> connection error of type ORIGIN_SET_SIZE_EXCEEDED. So even if a server
> can't control itself, at least it is given fair indication as to why
> clients are closing connections.
>
> Lucas
> ________________________________________
> From: Mark Nottingham [mnot@mnot.net]
> Sent: 02 October 2017 22:53
> To: Martin Thomson
> Cc: Patrick McManus; Mike Bishop; Bence Béky; HTTP Working Group; Erik
> Nygren
> Subject: Re: Working Group Last Call The ORIGIN HTTP/2 Frame
>
> ... and to be clear, the PR was about a server-sent SETTING; does anyone
> have feedback about Nick's idea regarding a client-sent SETTING?
>
>
> > On 1 Oct 2017, at 9:12 am, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > I'm not hearing wild enthusiasm for this, so I'm going to drop the PR.
> >
> > Cheers,
> >
> >
> >> On 27 Sep 2017, at 7:23 pm, Mark Nottingham <mnot@mnot.net> wrote:
> >>
> >> I'm OK either way here; it's attractive to have a deadline for knowing
> whether the connection is under the ORIGIN model (first SETTINGS), but I'm
> also a bit nervous about introducing such a big change relatively late in
> the day.
> >>
> >> Put another way - does anyone think that this is clearly better than
> the current spec and needs to get in?
> >>
> >> PR here (still needs some work if we want to adopt):
> >> https://github.com/httpwg/http-extensions/pull/406
> >>
> >>
> >>> On 28 Sep 2017, at 11:48 am, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >>>
> >>> On Thu, Sep 28, 2017 at 11:43 AM, Patrick McManus <
> pmcmanus@mozilla.com> wrote:
> >>>> I'm not going to object to the setting - it just seems it doesn't
> really
> >>>> address the fact that the client is going to see both 7540 rules and
> ORIGIN
> >>>> rules at some point on the same connection so there's not a lot of
> point to
> >>>> it imo.
> >>>
> >>> I see your point.  It narrows, but doesn't eliminate the window of
> >>> uncertainty and as a result it isn't that much use to you.
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >>
> >>
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------
>
>

Received on Tuesday, 3 October 2017 10:56:46 UTC