-
Notifications
You must be signed in to change notification settings - Fork 599
Pusher http compatibility #102
Comments
That looks like it's falling back to XHR streaming which is not implemented by this package only websockets. Try adding the
Then there is probably a connection error of some sort for it to resort to XHR streaming and not able to connect to you websockets server. |
That makes sense (probably should be in the docs though?) For some reason the websocket connection is indeed not established on the server (works fine locally) |
Yeah that should be in the docs (considering the many issues about it...). That can have a million reasons really :) Make sure you are using the certificate files (#92 (comment)) this bit a few people already and also you have both the local cert and pk config option set. If certificate is all good check if there are any message in the developer console of the browser that might give some insight in could be breaking. If there is no output at all in your browser console make sure you are not using a port that is not allowed by the browser (more about that here: https://alex.bouma.me/installing-laravel-websockets-on-forge/#a-note-about-ports). |
I did derp up and only included the PK. not the cert; however the issue seems to remain exactly the same after correcting the mistake. I've also (as per linked comment in #92) checked with more permissive permissions, to no avail. |
looks like my firewall was really acting up, opening port 6001 & disabling the firewall didn't seem to have been applied. so it's no longer timing out (thanks good old telnet for discovering that 😅 ) Note: as webmin generates the let's encrypt certificates, I don't have a "fullchain" as per the linked comment; however Let's Encrypt should be a recognized CA so I'm not sure if related, especially as I disabled client-side checks. (and without logs/errors it's very hard to debug) |
Looking at this it does still look like a certificate error: https://stackoverflow.com/questions/31664366/chrome-failing-to-connect-to-websocket-server-opcode-1-handshake-was-cancele. I don't think you need to do anything the accepted answer says, but do need to make sure the certificate (file) is correct. Maybe you could try to create your own There is currently no error if you supply an invalid or incomplete certificate (#92 (comment)) so that definitely doesn't help, but of a hit and miss right now :) |
I just checked and it seems to match with chrome failing; it works just fine under firefox I'll check; but that won't be a sustainable solution as our LE certificates change bi-monthly |
Running the concatenation in a cron should help with that (you need to restart your websocket server each the the certificate changes anyhow), but this is more a problem with webmin than this package I think (except the error reporting for an incorrectly configured certificate ofcourse). |
The concatenated version ended up with a further investigations lead me... nowhere 😅 Either way, I do believe having an option to include the intermediate certificates as a parameter instead of requiring to provide a combined file would be a more lenient solution; there's several CA's that don't provide a combined file, similar to what apache requires Above is a working configuration, to combine them I tried Thanks for the help so far, the issue might be broader than this package indeed; though I do believe if the configuration works for apache it should arguably work out for this too. |
Now I'm all out of ideas too, great problem! If you do find something it would be really useful to leave here or PR a documentation change to include your findings!
Well the current config for this package works for NGINX, so I guess arguments could be made for every server software that handles SSL just a bit differently (don't even get me started about IIS). As a general note, I would always place your websockets server behind a reverse proxy like NGINX (or I believe Apache can do the same) so the websockets server doesn't have to handle SSL at all and offload those CPU cycles to more competent and faster applications designed for that work, this way you also don't have to worry about restarting your websockets server when a certificate or config changes but restarting the proxy server (be it Apache or NGINX) is enough. This also has the benefit if your app being able to speak in plain text to the websockets server making it slightly faster. For inspiration: I wrote this blog for Forge & NGINX, that might give you some ideas on how to replicate it for Apache if you want to go that route. |
It looks like I missed Apache's support for reverse-proxying websockets before, and since (luckily) I don't seem to have a collision with Thanks a lot! as for documentation ideas/notes:
EDIT: note that, for some reason, I had to remove the proxypass, save, reload, add it again, save, reload for everything to work. |
Hello @jlsjonas . |
I will send my configs if you need. |
It looks like there's some incompatibilities with the pusher/echo client.
Above is trying to make a POST request to the url, however only GET & HEAD is allowed
The text was updated successfully, but these errors were encountered: