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
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.
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.
Activity
mnot commentedon Aug 18, 2014
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?
martinthomson commentedon Aug 18, 2014
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.
mnot commentedon Oct 7, 2014
SGTM (for the second part).
mnot commentedon Jan 21, 2015
Discussed in HNL; can be editorial.
mnot commentedon Feb 11, 2015
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).
reschke commentedon Apr 30, 2015
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?
mnot commentedon May 1, 2015
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.
MikeBishop commentedon May 28, 2015
Agreed -- requiring a PROTOCOL_ERROR if you understand something doesn't really make sense. Just drop it.
Unexpected Alt-Svc frames (#18)