-
Notifications
You must be signed in to change notification settings - Fork 142
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
Unexpected Alt-Svc frames #18
Comments
Somewhat similar, the next para says that intermediaries MUST NOT forward alt-svc. I understand what's being attempted here (intermediaries forming new altsvc based upon them, etc.), but the MUST NOT is going to confuse people; can we just do this in prose? |
I think that we can do what we do with push. That is, note that they are hop-by-hop and note that an intermediary is able to choose whether to forward them. Any ALTSVC frames an intermediary receives is merely input it can use to determine what it sends onward. |
SGTM (for the second part). |
Discussed in HNL; can be editorial. |
So, I think the plan is to a) talk about Alt-Svc as a hop-by-hop construct as Martin suggests, and b) drop the requirement to PROTOCOL_ERROR (but note that they'll just be ignored, and might cause the recipient to consider you to be hostile/broken, thus resulting in something similar). |
a) the PROTOCOL_ERROR requirement is on the server; that still makes sense, no? b) The spec already says: "The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT forward ALTSVC frames, though it can use the information contained in ALTSVC frames in forming new ALTSVC frames to send to its own clients." - so is there anything left to do? |
It's nonsensical that an implementation that doesn't support ALTSVC can ignore it (and as a recipient, no server implements ALTSVC), only to require servers to PROTOCOL_ERROR when receiving it. |
Agreed -- requiring a PROTOCOL_ERROR if you understand something doesn't really make sense. Just drop it. |
Section 4 requires PROTOCOL_ERROR on an ALTSVC frame. However, earlier we say that it's a non-critical extension, and can be ignored. Which is it?
Yes, we could make a distinction on "supporting the frame", but that doesn't seem to helpful.
Can we just drop the requirement and say it doesn't mean anything?
The text was updated successfully, but these errors were encountered: