Fixing jdownloader websockets

[therobbiedavis]

---

• I have read the contributing guideline and understand that I have made the correct modifications

---

Description

Websockets were failing when trying to connect via reverse proxy

Benefits of this PR and context

Fixes websocket failing to connect.

How Has This Been Tested?

Once change was applied websockets were able to connect.

Source / References

jlesage/docker-jdownloader-2#265 (comment)

[drizuid]

lgtm

[aptalca]

Thanks but have you tested this?

I do realize what we had before was incorrect, but the proposed fix also looks incorrect.

The reason is, when you use a variable in the proxy_pass line, nginx has this weird behavior where it automatically appends the location to the end of the proxy_pass address. Really weird behavior that is not really documented anywhere that I could find. It doesn't do that when you use an actual address like an ip or a dns hostname.

[therobbiedavis]

@aptalca Yes, currently using it and it works for me.

[drizuid]

Thanks but have you tested this?

I do realize what we had before was incorrect, but the proposed fix also looks incorrect.

The reason is, when you use a variable in the proxy_pass line, nginx has this weird behavior where it automatically appends the location to the end of the proxy_pass address. Really weird behavior that is not really documented anywhere that I could find. It doesn't do that when you use an actual address like an ip or a dns hostname.

i did not test (i dont use jdownloader), but i did look through jdownloaders forums and saw similar suggestions for npm and pure nginx. I will add, i saw a websocket path for audio as well, which we lack. i didnt mention it because im not sure our container even supports the audio portion, again, never used this :D

[aptalca]

Right, unfortunately most of those guides use an IP or a dns hostname so they don't hit that weird behavior. We use vars to make sure nginx doesn't complain and refuse to start when a proxied service is not up or reachable. Another weird nginx behavior.

That's why when we have a separate server block for api endpoints that bypass auth, we don't add /api to the proxy_pass line: https://github.com/linuxserver/reverse-proxy-confs/blob/master/bazarr.subdomain.conf.sample#L61

But if it works, I'm ok with merging it. @therobbiedavis can you update the date on the first line as well so it shows up in SWAG log as a conf that needs an update?

Thanks

[therobbiedavis]

Right, unfortunately most of those guides use an IP or a dns hostname so they don't hit that weird behavior. We use vars to make sure nginx doesn't complain and refuse to start when a proxied service is not up or reachable. Another weird nginx behavior.

That's why when we have a separate server block for api endpoints that bypass auth, we don't add /api to the proxy_pass line: https://github.com/linuxserver/reverse-proxy-confs/blob/master/bazarr.subdomain.conf.sample#L61

But if it works, I'm ok with merging it. @therobbiedavis can you update the date on the first line as well so it shows up in SWAG log as a conf that needs an update?

Thanks

@aptalca Done.