Skip to content
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

Alt-Svc and coalescing #1696

Open
martinthomson opened this issue Sep 28, 2021 · 1 comment
Open

Alt-Svc and coalescing #1696

martinthomson opened this issue Sep 28, 2021 · 1 comment
Labels

Comments

@martinthomson
Copy link
Contributor

In #1691 we are discussing the use of ORIGIN and it appears that there are some differences in how Alt-Svc is implemented when it comes to coalescing.

If you think of Alt-Svc as only applying to the creation of a new connection to an origin, then any discussion of ORIGIN has no real bearing on Alt-Svc as ORIGIN cannot cause the origin for which a connection was created (i.e., the origin identified in the TLS SNI field) to be disqualified.

If you view Alt-Svc as potentially applying to the selection of a connection that already exists, such as might happen if an Alt-Svc is identified by an IP address for which a connection already exists, then ORIGIN is relevant as use of the alternative service will result in requests to a new origin being coalesced onto that connection.

The Alt-Svc spec is not particularly clear about whether connections to alternatives are always freshly made or whether existing connections to an alternative can be reused. I believe that the principled position would be to allow for coalescing here, but to recognize that some clients will not do that (i.e., allow for both). Documenting these options and the implications of the different approaches would be wise, if only to ensure that servers are able to deploy alternatives with some reasonable expectations about what clients do.

@MikeBishop
Copy link
Contributor

We wound up with some ambiguity in http-core about whether a DNS check is required, and by implication, whether a separate Alt-Svc for each domain is required. It doesn't say that you MUST do a DNS check, it says that "In practice, a client will make a DNS query...." I read that as a statement of widely implemented behavior, not a requirement of the spec.

If you think only the cert matters, then you use Alt-Svc to open a connection, see all the hostnames on the cert, and proceed to use that alternative for everything mentioned in the validated cert. If you want a DNS check, then obviously DNS won't point to that alternative for those other names, so in the absence of an Alt-Svc pointing to the same host, you won't use that connection. You'll make a fresh connection, likely get another Alt-Svc, and discover that you could have used the connection you already had.

However, it also says that ORIGIN can be used to remove the DNS restriction. (It's still quite strange to me that we accept declarations about authority from a server we wouldn't be willing to make requests of. It's also strange that ORIGIN doesn't have a wildcard form that means "the cert is right.")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants