New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When can you coalesce connections #2223
Comments
I think that the intent was to present equivalent text. Though the thinking about coalescing has evolved some in the meantime. We should discuss where we think the state of this discussion is at and see if we can capture something sensible. |
Yes, it'd be good to capture something more up-to-date if we can come to consensus on that. Is explicit signal meant to indicate DNS and/or ORIGIN frame? If so, maybe call those two out as examples? |
@ianswett I think the dilemma is that some of those things don't exist yet for H3. For example, Mike did some earlier work to redefine ALTSVC frame for H3 but there is yet to be equivalent for ORIGIN or secondary certs. |
Yes, it's intentional. RFC7540 allows coalescing based on the cert and DNS, because you're connected to the authoritative origin. However, HTTP/3 is never connected on the authoritative endpoint for an http(s?):// URL, so you need something else to tell you that's okay. This could be an Alt-Svc record for that origin delegating to the same UDP port. This could be an ORIGIN-for-H3 frame telling you to throw caution to the wind and trust the cert, if the client thinks that's sensible. |
Discussed in London; also blocked on httpwg/http-core#194 defining how a client decides which connection / server to ask for a given resource. |
Discussed in ZRH. Waiting for HTTP changes to materialize. |
S 2.4.
This text seems quite a bit more restrictive than S 9.1.1. of RFC 7540,
which just allows reuse as long as the SAN is present in the cert. Is
that intentional?
The text was updated successfully, but these errors were encountered: