-
Notifications
You must be signed in to change notification settings - Fork 75
Data read from socket doesn't match expected length #95
Comments
Hello, and thank you for your exemplary bug report 👏! This is all clear. I can reproduce the bug. I have added some debug instructions directly into From the server:
From the client:
So, I guess |
Hello @okdana, thanks for this great report, I will work on it asap. |
This could also explain our issue related to TLS handshake. |
Do you have a clue on this one @Pierozi? |
Yes i've made some fix test. The max stream buffer size depend of the system and method used. We have to loop until the buffer is empty or the expected length is extracted. We have to deal with encrypted and unencrypted mode, because I will submit a PR soon. |
Short update here, we have two possibilities to solve this issue, depending of how the PR 53 on |
Hello!
I've been using
Hoa\Websocket
to interface with Chromium's debugging protocol in order to print PDFs. Chromium returns the PDF data in the response as a base64-encoded string, which can grow quite long (several MiB). I found that the response that i was getting back was the wrong size, usually severely truncated (tens of KiB).To rule out an issue with Chromium, i created a
server.php
that simply sends 5 MB of base64-encoded garbage back to the client on connect, and i made aclient.php
to just print the length of the bucket message it receives. This is my result:Ultimately the issue seems to lie in the call to
stream_socket_recvfrom()
withinHoa\Socket\Connection\Connection::read()
. I've confirmed that it receives the correct$length
, but the result never matches it.I'm creating the issue here rather than under
Hoa\Socket
because i'm assuming this has something to do with blocking or buffering settings rather than any flaw in theread()
method itself... but i'm not sure. Am i doing something wrong?Code to replicate:
server.php
client.php
The text was updated successfully, but these errors were encountered: