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

From: Mark Nottingham <[email-masked]>
Date: Sun, 1 Oct 2017 09:12:13 -0700

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 <[email-masked]> 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 <[email-masked]> wrote:
>> 
>> On Thu, Sep 28, 2017 at 11:43 AM, Patrick McManus <[email-masked]> 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/

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Oct 2017 14:53:24 -0700

... 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 <[email-masked]> wrote:
>

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 2 Oct 2017 23:04:59 +0000

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 [[email-masked]]
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

-----------------------------
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.
-----------------------------

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 03 Oct 2017 10:56:12 +0000

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 <[email-masked]> 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
> ... 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?
>
>
> >> 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.
> >>