A wildcard bind makes /System/Info report an address no client can use #119

New issue

Closed

opened 2026-08-13 23:52:02 +02:00 by Claude · 0 comments

Claude commented

2026-08-13 23:52:02 +02:00

Collaborator

Started with server.bind = "0.0.0.0:8095", /System/Info/Public answers:

"LocalAddress": "http://0.0.0.0:8095"

which is not somewhere a client can go. Measured twice while implementing and reviewing #112, on two different servers.

Upstream does not have a static value here. It computes the address per request from the caller — GetSmartApiUrl(HttpRequest) → GetBindAddress(remoteAddr) in src/Jellyfin.Networking/NetworkManager.cs — so a client asking over the LAN is told a LAN URL, a client asking over loopback is told a loopback URL, and a wildcard bind never leaks as a literal 0.0.0.0. Ours reads the configured bind and formats it.

This is separate from #112 and predates it. It surfaced there because the discovery responder had to answer the same question and now does it correctly: crates/jellyfin-server/src/discovery.rs resolves the interface that routes to the requester. That logic is what the HTTP route wants, so this issue is largely "share it", not "write it".

Two callers to fix, both reading the same configured value: /System/Info and /System/Info/Public.

Where to start

crates/jellyfin-http/src/routes/admin/system.rs builds both bodies; the value comes from the server configuration rather than from the request. The address selection already exists in crates/jellyfin-server/src/discovery.rs — moving it somewhere both can reach it is the architectural question, and ARCHITECTURE.md decides where, since jellyfin-core touches no sockets and the route handler does not know about interfaces.

Upstream also honours PublishedServerUriBySubnet and an explicit external-interface preference here. Neither exists in this port; say so rather than half-implementing them.

How to know it is done

With a wildcard bind, /System/Info/Public fetched over loopback reports a loopback URL and the same request from another machine on the LAN reports the LAN URL — and the value agrees with what the reference answers the same two callers. A specific bind keeps answering exactly what it answers today.

Started with `server.bind = "0.0.0.0:8095"`, `/System/Info/Public` answers: ``` "LocalAddress": "http://0.0.0.0:8095" ``` which is not somewhere a client can go. Measured twice while implementing and reviewing #112, on two different servers. Upstream does not have a static value here. It computes the address per request from the caller — `GetSmartApiUrl(HttpRequest)` → `GetBindAddress(remoteAddr)` in `src/Jellyfin.Networking/NetworkManager.cs` — so a client asking over the LAN is told a LAN URL, a client asking over loopback is told a loopback URL, and a wildcard bind never leaks as a literal `0.0.0.0`. Ours reads the configured bind and formats it. This is separate from #112 and predates it. It surfaced there because the discovery responder had to answer the same question and now does it correctly: `crates/jellyfin-server/src/discovery.rs` resolves the interface that routes to the requester. **That logic is what the HTTP route wants**, so this issue is largely "share it", not "write it". Two callers to fix, both reading the same configured value: `/System/Info` and `/System/Info/Public`. ## Where to start `crates/jellyfin-http/src/routes/admin/system.rs` builds both bodies; the value comes from the server configuration rather than from the request. The address selection already exists in `crates/jellyfin-server/src/discovery.rs` — moving it somewhere both can reach it is the architectural question, and `ARCHITECTURE.md` decides where, since `jellyfin-core` touches no sockets and the route handler does not know about interfaces. Upstream also honours `PublishedServerUriBySubnet` and an explicit external-interface preference here. Neither exists in this port; say so rather than half-implementing them. ## How to know it is done With a wildcard bind, `/System/Info/Public` fetched over loopback reports a loopback URL and the same request from another machine on the LAN reports the LAN URL — and the value agrees with what the reference answers the same two callers. A specific bind keeps answering exactly what it answers today.

Claude added the

correctness

http

operations

labels

2026-08-13 23:52:10 +02:00

Claude referenced this issue

2026-08-14 00:04:13 +02:00

Clients on the network cannot find the server: nothing answers UDP autodiscovery #112