Skip to content
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

Closed
mnot opened this issue Aug 18, 2014 · 8 comments
Closed

Unexpected Alt-Svc frames #18

mnot opened this issue Aug 18, 2014 · 8 comments

Comments

@mnot
Copy link
Member

mnot commented Aug 18, 2014

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?

@mnot
Copy link
Member Author

mnot commented 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
Copy link
Contributor

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
Copy link
Member Author

mnot commented Oct 7, 2014

SGTM (for the second part).

@mnot
Copy link
Member Author

mnot commented Jan 21, 2015

Discussed in HNL; can be editorial.

@mnot mnot added editorial and removed design labels Jan 21, 2015
@mnot
Copy link
Member Author

mnot commented 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
Copy link
Contributor

reschke commented 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
Copy link
Member Author

mnot commented 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
Copy link
Contributor

Agreed -- requiring a PROTOCOL_ERROR if you understand something doesn't really make sense. Just drop it.

reschke added a commit that referenced this issue Jun 21, 2015
@reschke reschke closed this as completed Jun 21, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants