search

fatg3erman / RompR

Web client for Mopidy and MPD
https://fatg3erman.github.io/RompR/
Other
190 stars 22 forks source link

Rompr wrongly assumes that is served on port 80 (http) or 443 (https) #131

Closed adrhc closed 2 years ago

adrhc commented 2 years ago 
Failed to construct 'WebSocket': The URL 'ws://192.168.1.32:81:6680/mopidy/ws' is invalid.

I set "Mopidy HTTP Interface Port" to 6680. The problem is that Rompr wrongly assumes that is served on port 80 (http) or 443 (https).

fatg3erman commented 2 years ago

What did you set the address for your Mopidy player to? I can't reproduce this.

fatg3erman commented 2 years ago

Sorry I should have read the log you helpfully provided :) Can you try using an IP address instead of localhost for Mopidy? localhost often gives strange problems and I don't like it.

As the debug info shows, the pref more mopidy_http_port is set correctly: 192.168.1.32:6680

So I have no idea where that :81 is coming from. Rompr makes no assumptions about which port it is served on.

fatg3erman commented 2 years ago

According to your debug info above, your server is running on Port 80. The mopidy websocket address, if mopidy is configured to use 'localhost', is created from a combination of the server-side variable HTTP_HOST (which you can see is set to an IP address, as it should be) and the mopidy HTTP port. There's nowhere in any of that info that points to port 81 being used anywhere in your setup, so it's a total mystery why it's there. It's as if the browser is adding it. If you enable debug logging you should see a message in the Javascript console that says 'MOPISOCKET Connecting to' and the the address the code is using.

adrhc commented 2 years ago

According to your debug info above, your server is running on Port 80

Right, I changed it to 80 otherwise I couldn't use Rompr; initially (before copying the debug information) was 81 and Rompr was accessible with http://**192.168.1.32:81**/index.php. When using 81 I get ws://192.168.1.32:81:6680/mopidy/ws (is pretty obvious from the js code why).

server {
    listen 81 default_server;
    listen [::]:81 default_server;

    root /var/www/rompr/;
    index index.php index.html index.htm;

    server_name raspberrypi;

    client_max_body_size 512M;

    error_page 404 = /rompr/404.php;

    # This section can be copied into an existing default setup
    location / {
        allow all;
        index index.php;
        location ~ \.php {
            include snippets/fastcgi-php.conf;
            fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
            fastcgi_read_timeout 864000;
        }
        # error_page 404 = /rompr/404.php;
        try_files $uri $uri/ =404;
        location ~ /albumart/* {
                expires -1s;
        }
    }
}
fatg3erman commented 2 years ago

OK so firstly, with reference to your other post, I think your error_page 404 should point to /404.php, because you've set your root to /var/www/rompr/. The error_page is a path relative to the server root. You should correct that.

I still don't understand why it's including the :81 in the prefs. Like I say, this is built up server-side, so unless HTTP_HOST includes the port number, and only does so when you use a non-standard port (which would make no sense) then it shouldn't be there.

If it's obvious from the js code why this is, please provide an example.

adrhc commented 2 years ago

I think your error_page 404 should point to /404.php

Thanks, I closed the other post because of this (you are right about it).

Sorry, somehow I missed the javascript error code where one can see that the ws:// part is computed dynamically in javascript (i.e. uses location.host in a script concatenation) - so, it's not built up server-side.

I can't reproduce it right now because I'm conducting a very long collection update but I'll paste the error as soon I can reproduce it.

fatg3erman commented 2 years ago

OK so in fact, it does do that. HTTP_HOST includes the port number, but only if you're using a non-standard port. This is because it's taking it from the HTTP header sent by your browser and your browser is trying to be "helpful".

I don't think there's a reliable way I can fix this. But if you use an IP address for your player - instead of 'localhost' - that should work because it removes the ambiguity around what 'localhost' actually means.

fatg3erman commented 2 years ago

There's absolutely nowhere in the code where I use location.host. Anywhere. At least not in the current release. It is definitely built server-side, there's PHP function called get_player_ip() that does it.

I have reproduced it here, but like I say I can't think of a way to fix it. I can't use 'localhost' because it's not necessarily 'localhost' as far as the browser is concerned. So I have to convert 'localhost' to an IP address, and it doesn't look like the server gives me any infomation I can trust to do that reliably.

adrhc commented 2 years ago

I'm sure the ws:// URL is computed in javascript; still indexing, I'll come back with the javascript code.

fatg3erman commented 2 years ago

Are you actually trying to explain to me how my own code works?

socket = new WebSocket('ws://'+prefs.mopidy_http_port+'/mopidy/ws');

prefs.modify_http_port is created in the backend by probe_http_api() and nice_server_address(), which used HTTP_HOST if the player address is 'localhost. End of discussion.

Open the Preferences panel, Edit Player,s and replace localhost with the IP of the machine your Mopidy is running on. Problem solved.