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

Adjust the handling of RSV1/RSV2/RSV3 in the translateSingleFrame #1232

Merged
merged 2 commits into from
Apr 8, 2022

Conversation

marci4
Copy link
Collaborator

@marci4 marci4 commented Apr 3, 2022

Related Issue

Fixes #1230

How Has This Been Tested?

Autobahn testsuite

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@marci4 marci4 requested a review from PhilipRoman April 8, 2022 07:01
@PhilipRoman
Copy link
Collaborator

PhilipRoman commented Apr 8, 2022

Looks good!

Just wanted to check if I understood the changes correctly.
In PerMessageDeflateExtension it now also decompresses when rsv1 is false and opcode is continuous (previously this combination was ignored).
In Draft_6455, if none of the rsv bits are set, fall back to default extension.

Is this correct?

Also, could there be an extension that doesn't use any rsv bits where this would fail? I didn't find anything in the standard about this.

EDIT: apparently there are only two extensions registered with IANA, so I would say it's not worth worrying about that. But the other one, bbf-usp-protocol does not use any RSV bits. So in the unlikely case that someone wanted to implement support for bbf-usp-protocol, the API would need to change.

@marci4
Copy link
Collaborator Author

marci4 commented Apr 8, 2022

Yes, we have to decompress always if the first frame has rsv1 set.

If the first frame has no rsv1 set, we have no compressed message and fall back to using the default extension

I am not aware of any other extension doing compressions without any rsv set

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CONTINUOUS should be decoded depending on the first frame
2 participants