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 13:01:01 UTC