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

You do run into a potential loop with that, interestingly.  If the uninitialized state is the set of origins in the certificate, but the server has used ORIGIN to reduce the number of origins for which it will use this connection, then a connection on which you've received an ORIGIN frame would always be a proper subset of a connection on which you haven't (yet, presumably).  This could lead to some interesting behaviors for clients which open multiple connections in parallel for various purposes, if done naively.

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

Hi,

(from the correct e-mail address this time, sorry to cc'd folks for duplicate e-mails)

On Sat, Sep 23, 2017 at 2:43 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On Sat, Sep 23, 2017 at 7:59 AM, Mike Bishop 
> <Michael.Bishop@microsoft.com>
> wrote:
>>
>> I’m a little surprised that the value before receiving an ORIGIN 
>> frame isn’t the set of origins in the certificate.  If the behavior 
>> is expected to be different in some manner for an uninitialized set, 
>> we should specify that case.  If not, why not simplify the logic by initializing the set?
>
>
> This is a backwards compatibility thing.  A server that doesn't 
> advertise ORIGIN doesn't support it, and is therefore only subject to the rules in h2.
> Which allow coalescing.  Local policy at the client might choose to 
> ignore this detail, of course.
>

My understanding is that the behavior dictated by RFC7540 rules is almost the same as the one prescribed by an Origin Set initialized to the set of origins in the certificate (MUST NOT reuse connection if the origin is not in the set, MAY reuse if it is according to RFC7540 and SHOULD according to ORIGIN specification with the client having quite some discretion according to both specs).  Not sure if backwards compatibility would suffer significantly.

In any case, if the origin set is uninitialized, then the penultimate paragraph of Section 2.4 should probably specify what proper subset means in that case.  Is the uninitialized set considered to be the set of origins in the certificate for the purposes of that paragraph?  Or is a connection without an initialized Origin Set not covered by this paragraph?

Cheers,

Bence

Received on Monday, 25 September 2017 16:51:35 UTC