- From: Nick Sullivan <nicholas.sullivan@gmail.com>
- Date: Tue, 03 Oct 2017 10:56:12 +0000
- To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Bence Béky <bnc@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Erik Nygren <erik@nygren.org>
- Message-ID: <CAOjisRzxwFnHzo=Zf2zjZCvo6o4Uyk5S98jvFZR6f4PRCia7rQ@mail.gmail.com>
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