-
Notifications
You must be signed in to change notification settings - Fork 137
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
Conflicts between Alt-Svc and ALPN #72
Comments
|
Yes, that's a bad sort of failure, but I don't think that it needs special handling. Any failure in establishing the alternative just results in falling back to the primary. (BTW, h2c has to mean one thing, and I think that it's clear that this is Upgrade.) |
|
Maybe some security considerations text to the effect that the alternative isn't usable if it doesn't negotiate the advertised protocol. |
|
s/security considerations//; just text. |
|
Discussed on list, add text. |
|
in 2.4? |
|
Makes sense to me. |
|
@reschke do you need text to be proposed? |
|
yes |
Wrong protocol is connection failure (#72)
Alt-Svc tells me to use h2, so I open a TLS connection, and the server either doesn’t support ALPN or doesn’t select h2. What now? Weird corner cases ensue where I’m connected to something that may or may not be the alternate I was intending to reach. (Similar issues ensue attempting to connect using h2c -- does it mean a direct TCP connection to the specified port, or that the client should offer Upgrade? What if the server doesn't accept the Upgrade?)
It's simpler to just say TLS is the protocol and require ALPN support in 2.3 as well. Point me to a TLS-enabled endpoint, and the specific protocols we'll use will be negotiated in real-time.
However, this does pose a challenge if you wanted only HTTP/3 traffic going to your alternate.
The text was updated successfully, but these errors were encountered: