How to move the websocket URL to /ws ?

[12u...@gmail.com]

Nitrogen with nginx reverse proxy

---------------------

Hi Nitrogeners,

Chromium developer tools shows an error : "WebSocket connection to <my_ bioutifoul_page> has failed, falling back to AJAX".

From all I read, especially : https://serverfault.com/questions/910805/proxy-websockets-and-http-through-the-same-location-in-nginx , the nginx WebSocket reverse proxy configuration MUST be put on a separated URL (an nginx location /ws{…} block) to be functional, such as : /ws, so, how can I achieve that ?

Jean-Yves

[Jesse Gumm]

Hey Jean-Ybes,

I'm making a guess here, but you may just need to make sure the nginx has p[assing through the necessary websocket headers:

In your server's nginx config file:

server {

     ...
     location / {
         proxy_pass http://127.0.0.1:8000;
         proxy_set_header Host $host;

         # WebSocket support (nginx 1.4)
         proxy_http_version 1.1;
         proxy_set_header X-Forwarded-For $remote_addr;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection "upgrade";
     }
}

-Jesse

--
You received this message because you are subscribed to the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nitrogenweb...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/cab646a3-c54d-4b04-8941-5441d9a86c62n%40googlegroups.com.

--

Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[12u...@gmail.com]

Hey Jesse,

I already have these :/

As the Chromium dev tool seems to have alternative views (sometimes complain about WS, sometimes not), I commented all other headers to keep only those you talk about, then I made a capture with WireShark launch on the client machine :

* when loading a page with a direct connection to nitrogen_srv:8000, I see 4 with lines into WireShark :

    cli → srv   Src port:39368    Dest port:8000    WebSocket Binary [FIN] [MASKED]   Length:401

    cli → srv   Src port:39368    Dest port:8000    WebSocket Binary [FIN] [MASKED]   Length:106

    srv → cli   Src port:8000    Dest port:39368   WebSocket Binary [FIN]   Length:502

    srv → cli   Src port:8000    Dest port:39368   WebSocket Binary [FIN]   Length:119

* but when I'm connected to nginx_srv:443, there are no WebSocket lines.

The nginx pkgs installed are : nginx-common   1.18.0-6.1and nginx-extras   1.18.0-6.1 on a Debian bullseye.

When you say "nginx 1.4", do you mean "since version 1.4" or is it the last version you compiled (something like debian nginx V. 1.14.n) ? (shall I compile nginx from source ?)

Jean-Yves

[12u...@gmail.com]

Forgot one question: are you _absolutely_ sure yours is correctly proxying WebSocket ?

JY

[Jesse Gumm]

Hey Jean-Yves,

I am indeed absolutely sure it is proxying the websockets (running nginx 1.18.0 on ubuntu)

Yes, the 1.4 comment means "since 1.4"

If you look at the network tab in the chrome dev tools, you should be able to see the websocket request, view the response headers, etc.

BTW, which backend server are you using?

Here's the example from nitrogenproject.com (which uses nginx as the reverse proxy).

-Jesse

To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/e1f53968-9e6f-4cf4-b9e3-059829091a41n%40googlegroups.com.

[12u...@gmail.com]

> I am indeed absolutely sure it is proxying the websockets (running nginx 1.18.0 on ubuntu)

Ok, so we have almost the same version of nginx, good.

> If you look at the network tab in the chrome dev tools, you should be able to see the websocket request, view the response headers, etc.

> Here's the example from nitrogenproject.com (which uses nginx as the reverse proxy).

I see them.

> BTW, which backend server are you using?

Huu, nitrogen (on my laptop: x86-amd64)

Ohhh, I (and you too;-p) missed one thing that just popped: WS packets can't be seen when connecting to nginx_srv:443 because of encryption ! (and as far as the headers are correct, no problemo).

In fact, I did not see I had a bad second member on an add-header, once modified, dev tool stopped to complaint (so it was not "alternative view" as I stupidly wrote).

So, this is solved - thanks for your swift answers and sorry for the noise.

Jean-Yves

[Jesse Gumm]

Glad you got it sorted out! 

-Jesse

To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/e6dd13b7-c428-456a-b313-2662540086c6n%40googlegroups.com.

[12u...@gmail.com]

For WITW, Firefox dev tools has more possibilities than those of Chromium (and for others if they need this one day).

* On the client, open dev tools (CTRL-SHIFT-i),and dock it to the bottom of the screen,

* click "Debugger" on the top bar,

* unfold "Main Threadé (at the left) and click on the server's name,

* at the right, go down until you found "Event Listener Breakpoints" and unfold it,

* at the right of "Event Listener Breakpoints", check "Log",

* also check: "Websocket" and "XHR" below,

* reload the page

This way, all WS traffic appears underneath, saying: bla, bla, "open { target: WebSocket isTrusted: true", etc…

JY