ratchetphp / rfc6455 Goto Github PK

Update the code base with language return type declaration on all methods/functions against the v0.4 branch.

• Add PHP 8 and 8.1 to GitHub Actions CI testing
• Update PHPUnit version used to test

Sourced from ratchetphp/Ratchet#392

onData can receive another frame before $onMessage completes and $this->messageBuffer gets null'd out, corrupting the messageBuffer.

MessageBuffer.php:99

if ($this->messageBuffer->isCoalesced()) {
    $msgCheck = $this->checkMessage($this->messageBuffer);
    if (true !== $msgCheck) {
        $onControl($this->newCloseFrame($msgCheck, 'Ratchet detected an invalid UTF-8 payload'));
    } else {
        $onMessage($this->messageBuffer);
    }

    $this->messageBuffer = null;

...

Hi @cboden ,

I would like to help out. Can you give me an idea about what would be helpful to you and maybe some high-level direction?

The server negotiator incorrectly suggests 0 as a subprotocol to the client when the client does not offer a subprotocol in the request but the server requires it.

See: ratchetphp/Ratchet#594

As per ratchetphp/Ratchet#226

The package guzzlehttp/psr7 v2.0.0 was released on the 2021-06-30. Could you consider adding support for this version?

At this time, people using ratchet/rfc6455 need to downgrade to guzzlehttp/psr7:^1.0.

With the Autobahn test suites now running on different ports for client/server we could investigate running them concurrently in GitHub Actions. This would reduce the number of jobs in half and possibly run the whole suite faster.

Newer versions of zlib do not support 8 bit deflate windows:

madler/zlib@049578f

This causes deflate_init to fail if 8 bit window is requested. (Specifically autobahn test 13.3.1)

I'm getting this error message:

249999999.75 is not a valid maxFramePayloadSize

From this piece of code:

I think there should be some value checking after dividing the system memory limit by 4.

Hi,

We are using RatchetPHP in an Home Automation Plugin.
The Home Automation system is named Jeedom (pretty famous in France).
The plugin is jMQTT which is used to handle MQTT protocol in Jeedom.

Some of our users are running this system on Raspberry Pi which is by default under a 32bits OS.

We found out that when sending a payload bigger than ~65K ratchetPHP raise an error on 32bits OS/PHP.

Issue is here (French) :
https://github.com/Domochip/jMQTT/issues/121#issuecomment-992824648

The error message is pretty clear :
PHP Warning: unpack(): 64-bit format codes are not available for 32-bit versions of PHP in /var/www/html/plugins/jMQTT/resources/vendor/ratchet/rfc6455/src/Messaging/MessageBuffer.php on line 163

I'll submit a PR to improve this management of "payload_length" like this :

• 64Bits OS/PHP : Nothing change, works like today
• 32Bits OS/PHP : Handle "payload_length" as a 32bits integer. It will then crash for a payload over than 2GB (instead of 65K today)

What's your mind about that?

Hello,
Is it possible or not-too-stupid to package only the Ratchet\RFC6455\Messaging namespace?

I am making a small HTTP/1.1 server crammed with only necessary features and I'd like to add websockets.
However, I don't want guzzle and I'll implement handshake myself.

I can just copy the namespace, but if (unlikely) my little project evolves to publish-worthy, I don't want to pull guzzle and psr interfaces.
Otherwise, my options would be to copy the Messaging folder and reference where I got it from (if license does not change in future).
Or implement RFC6455 from scratch, which I don't want to do.

I use this project: https://github.com/ratchetphp/Ratchet And I test simple example code in the main page, And this was used from current project.

So, I get this error with specific server:

Connection closed (1002 - Ratchet detected an invalid reserve code)

I don't have any problem with another servers.

It is strange that the message is sent, and problem is just for getting new data.

And the server don't have problem because the html code can connect and works to it.

react/socket (which replaces react/socket-client) is incompatible with ratchet as a result of incompatible react/stream requirements

It is possible to crash the WS server rather quickly by sending a frame header designating the size to be the maximum (8 x FF bytes).

PHP only has signed int natively, so this large number ends up being "-1" after being parsed by getPayloadLength() of Messaging/Frame.php.

Since that same function uses recursion to compile the length AND uses the special value of "-1" to know it needs to keep calling itself, one simple packet results in the server falling into an endless loop of recursion, eating up all the memory while using max CPU and eventually being killed by the kernel.

Even despite this issue, sending a bunch of nonsense to the server in loop to be picked up will consume a lot of memory without any boundaries and what's even worse, the memory stays reserved even after the client has disconnected. The garbage collector doesn't seem to clean it up even after some time has passed and more flooding from another client after the connection of the first one has closed.

• There should be a sanity check or a maximum frame size / message size setting (maximum whatever PHP supports so the length never ends up being < 0)

• Memory should be cleaned up after a message is processed or the client has disconnected

Thanks.

Dear,
When trying to open a connection from firefox 44.0.2, it fail everytime because Connection header is not just "Upgrade" as expected. This fix search for the string inside all "Connection header"

0001-fix-error-400-Connection-header-MUST-be-provided-wit.patch.txt
Disabled link, see updated fix on second comment