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

Binary packet placeholder handling does not handle all possible messages #275

Open
kelnos opened this issue Feb 28, 2024 · 0 comments
Open
Assignees
Labels
bug Something isn't working

Comments

@kelnos
Copy link
Contributor

kelnos commented Feb 28, 2024

Describe the bug

When a socketioxide-based server receives a binary event, it only handles _placeholders in two simplistic ways:

  1. If the payload is an array, it looks for objects in that array with a _placeholder key, and counts and removes them.
  2. If the payload is an object, it looks for a _placeholder key in the root of the object, and discards the entire object if it finds it.

However, binary events can have arbitrary object structures. For example, it might look like:

{
  "id": 42,
  "body": { "_placeholder": true, "num": 0 }
}

socketioxide believes this structure contains zero binary payloads, and how the logic for processing incoming binary blobs works, this packet will never end up being complete, as a packet is only ever complete if its determined payload count is equal to the number of payloads received. (After the first binary payload is received, 0 == 1 will fail.)

To Reproduce

  1. Create a simple socketioxide server that listens for a "test" event.
  2. Using a non-socketioxide client, send a "test" event with a payload as in the above description.
  3. See that socketioxide never passes the event to its handler, and in fact never believes the packet is complete.

Expected behavior

The socketioxide server should receive the packet, understand when it is complete, and call the event handler.

Versions (please complete the following information):

  • Socketioxide version: 0.8.0 (though inspection of 0.9.x and 0.10.x show they have the same issue)
  • Http lib: warp 0.3
  • Socket.io client version: Java io.socket:socket.io-client:1.0.1

Additional context

I was going to write a bit here how the socketioxide handler API makes it ambiguous as to where the binary payloads "fit" into the data payload when we consider more complex data payload structures, but I think that warrants a separate issue, so I'll file that in a bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants