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

Comments

Projects
None yet
4 participants
@mnot
Copy link
Member

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 mnot added alt-svc labels Aug 18, 2014

@mnot

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Member Author

commented Oct 7, 2014

SGTM (for the second part).

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jan 21, 2015

Discussed in HNL; can be editorial.

@mnot mnot added editorial and removed design labels Jan 21, 2015

@mnot

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

commented May 28, 2015

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 Jun 21, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.