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

An ORIGIN_SUPPORT setting works for me.  If it's unset, the origin set is what's in the cert; if it's set, the origin set is only the origin you opened the connection for (SNI et al.) and the server has to explicitly add anything else.

Which would mean it also functions as a do-not-coalesce setting, if the server sets it and then never sends an ORIGIN frame.  IIRC, some people wanted that model, and now it would exist fairly simply.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, September 25, 2017 10:11 PM
To: Mark Nottingham <mnot@mnot.net>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Bence Béky <bnc@chromium.org>; Patrick McManus <pmcmanus@mozilla.com>; HTTP Working Group <ietf-http-wg@w3.org>; Erik Nygren <erik@nygren.org>
Subject: Re: Working Group Last Call The ORIGIN HTTP/2 Frame

On Tue, Sep 26, 2017 at 12:15 PM, Mark Nottingham <mnot@mnot.net> wrote:
> On 26 Sep 2017, at 9:59 am, Martin Thomson <martin.thomson@gmail.com> wrote:
>>
>> I think that
>> we should also write down that ORIGIN SHOULD be sent before any 
>> responses and that once responses have been received, the client MAY 
>> assume that the server doesn't support ORIGIN.
>>
>> Is that a fair assessment of where we are at?
>
> Are we starting to use a frame for something that would be better expressed as a setting?

I do try to avoid adding mechanisms, but I think that you are right here.  An I_WILL_SEND_ORIGIN flag would avoid any messing around.

Received on Tuesday, 26 September 2017 15:52:02 UTC