You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.")
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.
The text was updated successfully, but these errors were encountered: