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. > > - The initialization on receipt of the first ORIGIN frame having the > wrong port in the case of Alt-Svc feels a bit weird. Given that this is an > H2 extension, and H2 includes the port in the :authority pseudo-header, why > is this not initialized to the authority (including port) of the origin for > which the connection was generated? Otherwise, we wind up considering the > server authoritative for an origin for which the server has never claimed > to be authoritative. While I can’t think of an obvious attack, this feels > like an opening that’s asking to be exploited some day. > > Same as above. If you connect without seeing ORIGIN, you will assume that the server is OK. However, once it is connected, we want to start from a minimal set and that has to be something that both client and server can easily agree on.
Received on Saturday, 23 September 2017 06:43:49 UTC