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
Persistence #291
Comments
origin set is defined per connection not (ironically) per origin.. so I'm not sure how this would work. |
2 loadbalanced hosts could have different sets of certs even if they answered to the same SNI on the same (public) IP.. I don't know how you could persist that. |
Yeah. I think there are a lot of ways we could mess up here. If you think of the binding as between a set of origins and a connection, AIUI what's being posited here is that it might be interesting to re-attach that binding to a new connection. It might be interesting if the server could associate a token with a particular set, and then have a dance where its use can be explicitly negotiated. Question is whether it's worth the effort (we've already tried to over-engineer this thing a few times). |
Agreed that persisting across connections seems like it may add too much risk and complexity and further additional interactions, especially if we include hosts not found through the DNS. (And doesn't even make sense with some of the changes made to not always rely on DNS.) |
Seems like there's no support for this ATM, closing. Comment if you disagree. |
Dare we specify that clients MAY/SHOULD persist origin information for a given endpoint beyond the lifetime of the connection?
The text was updated successfully, but these errors were encountered: