Support for non-standard(80/443) ports in self-hosted deploymenets behind Nginx

[eyespore]

Hi!

I've been testing self-hosted deployment of ClipCascade behind an Nginx reverse proxy on a non-standard HTTPS port (e.g., 8743). I noticed that when accessing the service on this port, the backend most of the time returns redirects that do not preserve the port, causing clients to be redirected to the default HTTP port 80, preventing them from reaching the actual service.

I've seen this issue mentioned in another discussion (#38). The backend seems to tend to redirect the frontend to HTTP. In that discussion, the problem was addressed by adding a rule to the reverse proxy that redirects requests from port 80 to 443. This works as long as the host's ports 80 and 443 are not blocked by a firewall. However, if those ports are blocked and a non-standard port must be used, this solution no longer works.

Currently, to make it work correctly with Nginx, I had to add a proxy_redirect rule like:

proxy_redirect http://$host/ https://$host:8743/;

This fixes the problem and ensures that clients are redirected to the correct port. As a reference, here's the Nginx configuration that worked for me when hosting the service on a non-standard port (8743) behind a reverse proxy (adapted/fixed from #93). It might help others facing similar issues.

server {
  listen 8743 ssl;
  listen [::]:8743 ssl;

  server_name example.com;
  ssl_certificate certs/fullchain.pem;
  ssl_certificate_key certs/privkey.pem;
  
  location / {
    proxy_pass                                      http://clipcascade:8080;
    proxy_ssl_verify                                off;
    proxy_set_header        Host                    $host;
    proxy_set_header        X-Real-IP               $remote_addr;
    proxy_set_header        X-Forwarded-Host        $http_host;
    proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto       $scheme;
    proxy_set_header        Upgrade                 $http_upgrade;
    proxy_set_header        Connection              "upgrade";
    proxy_buffers           8                       64k;
    proxy_busy_buffers_size                         128k;
    proxy_buffer_size                               64k;
    proxy_http_version                              1.1;

    proxy_redirect http://$host/ https://$host:8743/;  # fix the problem
  }

  # To support websockets
  location /clipsocket {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-NginX-Proxy true;

    real_ip_header X-Real-IP;
    proxy_connect_timeout 300;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Origin '';
    proxy_pass http://clipcascade:8080/clipsocket;
  }
}

Since the backend appears to generate URLs based on the host and scheme but not the external port, it seems that deployments on non-standard ports require manual proxy configuration to work correctly. I understand this may be a black-box setup from the backend side, so I'm not certain if there are any caveats or edge cases with this approach.

Would it be possible to improve the backend handling of non-standard ports, or provide documentation/guidance for self-hosted users deploying behind reverse proxies on arbitrary ports?

Thanks!