Close sessions which originSet is fully covered by other sessions and reuse those

[szmarczak]

See https://nodejs.org/api/http2.html#http2_event_origin

[pietermees]

More details on when connection coalescing is allowed can be found in the RFC: https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-06#section-2.4

[szmarczak]

Specifically, such clients [...] SHOULD use the connection for all requests to
origins in the Origin Set for which the connection is authoritative,
unless there are operational reasons for opening a new connection.
...
Because ORIGIN can change the set of origins a connection is used for
over time, it is possible that a client might have more than one
viable connection to an origin open at any time. When this occurs,
clients SHOULD NOT emit new requests on any connection whose Origin
Set is a proper subset of another connection's Origin Set, and SHOULD
close it once all outstanding requests are satisfied.

So as I understand it if I got two connections:

• connection A with an authority of A and B
• connection B with an authority of B

And I want to make a request to B I should use connection B instead no matter what?

[pietermees]

I think it's saying the opposite: you should use connection A and close connection B as soon as it finishes processing all outstanding requests, so you can keep 1 connection alive for both origins?

[szmarczak]

clients SHOULD NOT emit new requests on any connection whose Origin
Set is a proper subset of another connection's Origin Set, and SHOULD
close it once all outstanding requests are satisfied.

Connection A contains the authority of B, which is a proper subset of connection B. OTOH, it says

whose Origin Set is a proper subset of another connection's Origin Set

Does it refer to the whole Origin Set or just a part of it?

[szmarczak]

From https://httpwg.org/specs/rfc7540.html

An origin server might offer a certificate with multiple subjectAltName attributes or names with wildcards, one of which is valid for the authority in the URI. For example, a certificate with a subjectAltName of *.example.com might permit the use of the same connection for requests to URIs starting with https://a.example.com/ and https://b.example.com/.

In some deployments, reusing a connection for multiple origins can result in requests being directed to the wrong origin server. For example, TLS termination might be performed by a middlebox that uses the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an origin server. This means that it is possible for clients to send confidential information to servers that might not be the intended target for the request, even though the server is otherwise authoritative.

[pietermees]

@szmarczak could you clarify what you find confusing the origin set RFC language? I think it clearly states that if you have a connection that is authoritative for a set of origins that are already fully covered by another connection, you should close the former. This makes sense as the more valuable connection is the one with the larger encompassing set?

Regarding RFC7540, I think it simply states that in some scenarios connection reuse can end up sending data to the wrong server. That happens because SNI happens at connect time when you were trying to reach origin A, but now you’re reusing the same connection for origin B. The spec resolves this potential issue by having the server send a 421 error and allowing the client to retry the request on another connection (for example one explicitly established to origin B).

In summary:

1. A connection originally established for origin A can be reused for origin B if that connection is also authoritative for B
2. Authoritative is determined by
   • DNS resolving to the same IP:port for http
   • (DNS resolving to the same IP:port OR having an ORIGIN frame that indicates authority) AND having TLS subjectAltName authority
3. If one connection’s authority is a subset of another’s, you can close the former
4. If connection reuse ends up sending a request to the wrong server, that server should respond with a 421 and you are allowed to retry on another connection.

[pietermees]

https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-06 further clarifies that ORIGIN helps address two issues:

1. Preventing 421 responses and when they do happen how to manipulate the connection’s origin set to prevent further issues.
2. Relax the need for DNS resolving to the same IP before you can reuse a connection. Note that this involves its own security considerations which are outlined in section 4 of the ORIGIN draft RFC

[szmarczak]

I don't understand the meaning of proper in:

clients SHOULD NOT emit new requests on any connection whose Origin
Set is a proper subset of another connection's Origin Set

What's considered a proper subset? In my example server B holds the primary authority of B. Server A provides two valid authorities: A and B.

Does it refer to the primary authority? IOW:

First, you want to exchange some data with B. So you connect to server B, which holds the primary authority of B. Then, you connet to server A and it has two valid authorities: A (note: A is not owned by B, they're two different parties) and B. What should you do? What's the proper Origin Set?

[pietermees]

Proper subset just means that one is contained in the other, but not equal: http://mathworld.wolfram.com/ProperSubset.html

…

On Sun, Jul 28, 2019 at 7:57 AM Szymon Marczak ***@***.***> wrote: I don't understand the meaning of *proper* in: clients SHOULD NOT emit new requests on any connection whose Origin Set is a *proper subset* of another connection's Origin Set What's considered a proper subset? In my example server B holds the primary authority of B. Server A provides two *valid* authorities: A and B. Does it refer to the primary authority? IOW: First, you want to exchange some data with B. So you connect to server B, which holds the primary authority of B. Then, you connet to server A and it has two valid authorities: A (*note: A is not owned by B, they're two different parties*) and B. What should you do? What's the *proper* Origin Set? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17?email_source=notifications&email_token=ABW6KJIXZ2YAQZELMHO4V63QBWCT7A5CNFSM4IFDWSP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD265FAA#issuecomment-515756672>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABW6KJOA6Z6JH5AI4ELPYGTQBWCT7ANCNFSM4IFDWSPQ> .

[szmarczak]

Ah, my bad. Thanks for the explaination! Sorry, I didn't know that these are math keywords. I'm not native English :P Again, great thanks. You've been right from the beginning. I'll try to make a PR ASAP.

[pietermees]

No problem at all, these things can be confusing! Glad I was able to help :)

…

On Sun, Jul 28, 2019 at 11:30 AM Szymon Marczak ***@***.***> wrote: Ah, my bad. Thanks for the explaination! Sorry, I didn't know that these are math keywords. I'm not native English :P Again, great thanks. You've been right from the beginning. I'll try to make a PR ASAP. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17?email_source=notifications&email_token=ABW6KJL66CA5DS43TBY3ECLQBW3Q5A5CNFSM4IFDWSP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD27A5KI#issuecomment-515772073>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABW6KJIS4YABIDLKSTWOUTLQBW3Q5ANCNFSM4IFDWSPQ> .

[szmarczak]

@pietermees I understand the part above. So if I got this:

• connection A with an authority of A and C,
• connection B with an authority of B and C,

and I want to make a request to C, it doesn't matter whether I choose A or B? (I can't create a C connection because it would violate the RFC)

[pietermees]

@szmarczak correct, that's my understanding as well!
You'd be free to pick either one. A good path in this case might be to use the connection that was most recently used for a request? That would direct traffic to the most active connection and allow an unused one to potentially get closed due to being unused at some later point?

[szmarczak]

@pietermees You may want to see #21 (there are two todos left). I haven't made the tests yet.

[szmarczak]

Finished that todos. I just need to add some RFC comments so it's easier to understand the code and make the tests.