Emby, and hence Jellyfin, had a bit of a problem trying to be “everything”, especially in its implementation of a custom webserver. This has ultimately resulted in a number of problems both for advanced administrators, as well as causing numerous problems with apps (requiring “WAN IP”, HTTP Chromecast removal in Chrome 72, etc.)
There has already been discussions about using Kestrel as the webserver, and that is a good idea. However, I have a more expansive idea to help us eliminate the current woes.
Fundamentally I think the problem is that Jellyfin will always assume that it is a proper webserver, capable of serving HTTP and HTTPS directly on the listening IP and port, without any concern for reverse proxies, etc. This is, frankly, bad app design - it introduces a huge amount of complexity just in order to have a “port” field in the UI.
Very very few other apps work this way. For instance, Django apps, NodeJS apps, and a lot of Ruby apps are instead designed to always run behind a webserver/reverse proxy, such as nginx. Frankly, I don’t see why we can’t or shouldn’t go this route as well.
The end goal with this plan would be to have a simple API running in the core server, listening on a single port (configurable, not via UI, but via a proper configuration file or an environment variable) likely on
localhost, with nginx installed to both proxy the API as well as, if the (now-optional) WebUI within its webdir. The API can pretty much handle what it does now, but we could have it properly respond to proxy headers from NGinX, and encourage putting nginx in front of it.
This plan also serves as a double-edged sword for fully splitting out the Jellyfin web interface - we can always then assume we have a webserver running, and handle that properly.
The main downside I can see with this method is in installation: it’s “less easy” than just running a binary and going to the port. But it’s more flexible instead.
Our deployment guides would just need to be updated with this new setup procedure, and we could leverage platform-specific install scripts, OS packages, and tools like Ansible. Yes, this is a bit more complex for “ordinary” users, requiring nginx and the web UI, but a proper installer should solve that problem in each OS.