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

Checking frame type encoding? #2155

Closed
ekr opened this issue Dec 13, 2018 · 5 comments
Closed

Checking frame type encoding? #2155

ekr opened this issue Dec 13, 2018 · 5 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@ekr
Copy link
Collaborator

ekr commented Dec 13, 2018

encoded as a single byte with the value 0x07.  An endpoint MUST treat the
receipt of a frame type that uses a longer encoding than necessary as a
connection error of type PROTOCOL_VIOLATION.

Why does this requirement exist? It seems like an odd place to be
picky when we're generally allowing implementations to do unusual
things without requiring checking. To be clear, I'm fine with the
shortest encoding rule, but the must check seems unnecessary
and inconvenient.

@mikkelfj
Copy link
Contributor

I believe this is because it allows for fast switch statements in frame processing. It is what makes it affordable to use varints in extension frames. For two byte+ this could be relaxed, but even here, it allows for faster lookups. The situation is different where varints represent countable entities.

@ekr
Copy link
Collaborator Author

ekr commented Dec 13, 2018

No. That's a reason to require that you encode deterministically, not that you check

@MikeBishop MikeBishop added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Dec 13, 2018
@martinthomson
Copy link
Member

A MAY would have the intended effect.

@ekr
Copy link
Collaborator Author

ekr commented Dec 14, 2018

Yep. I would be fine with a MAY, i just understood that filing issues rather than PRs was right.

@martinthomson
Copy link
Member

Issues are probably best if there is a design change involved (as there is here - sort of). PRs are always good.

@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Development

No branches or pull requests

5 participants