host url validation failed

[puschie286]

the url validation fails on this (simple) url: http://homestorage:8096

[JustAMan]

I guess that's because you don't have a TLD in the URL.

[heyhippari]

If homestorage is an mDNS name, the TV might not know how to resolve it, as well.

[puschie286]

it works with disabled validation - it would be nice to be able to use this type of url but I don’t know enough about regex to solve this by myself

[JustAMan]

How did you make this hostname? There's a specific TLD for such cases - .local, so it should really be homestorage.local

[puschie286]

It was created automatically by synology init setup - so I’m not sure what technology is used

[JustAMan]

Try http://homestorage.local:8096 instead

[Clickbaitcake]

@puschie286 this isnt an issue with JellyFin its just how networking... works. You need to use the address suggested by @JustAMan OR use the IP address of the synology box. For example: http://192.168.0.20:8096

[oddstr13]

I actually regularly use plain hostname for my LAN services. It may not be the best way to do things, but it is convenient, and it works for the most part. Most important for this issue however, is that https://example/ is a fully valid URL, and I've yet to encounter a browser that doesn't accept it. Whether it resolves properly is dependent on the underlying OS and network configuration.

[JustAMan]

Well, we can probably relax the validation here: https://github.com/jellyfin/jellyfin-webos/blob/master/org.jellyfin.webos/js/index.js#L177-L180

[dovecode]

I suggest eliminating the validation altogether. Instead of attempting to capture any possible current and future formatting of IP addresses and host names with that abomination of a regex.

What is the reason that we're attempting to validate the URL in the first place? I'd apply the robustness principle here and try to be a bit more forgiving with the inputs. They are, after all, supplied by a human, not a machine.

Isn't it enough to just check for an empty string and then have a reasonable behavior, e.g. if there's no protocol, try https first and if that fails, try http. The network layer can tell us if the connection succeeded. If we have an opinion of a well-formatted URL, we can specify that as a help text.

By the way, an unqualified host name is a perfectly valid address. The client is expected to use the default domain (in DHCP and most *nix implementations of DNS, this is specified as the search domain). Attempting to guess how the underlying DNS resolving should work seems pointless.

[anthonylavado]

Since I wasn't involved with directly writing this, this is the first time I'm seeing that line with the validation. Sounds like a good idea to change it.

Looks like I'll be learning how to just check if the string is empty.

For the concern on a protocol, there is a "normalizeURL" function close to there that does assume HTTP if nothing is specified. While I likely won't be able to completely change that to try both protocols myself, I will accept that HTTP is the most likely scenario in a home situation and I think it would be wise to try that first. There also appears to be help text that advises the user to check if that's correct.

Action Plan:

• Loosen URL entry restrictions to checking for an empty string
• Create an issue to further enhance URL testing by checking/testing both protocols

[besendorf]

Did you make any progress on this @anthonylavado ? I just installed the new jellyfin-webos release and ran into this issue. btw: .local is not the intended tld for local networks this is .home.arpa https://datatracker.ietf.org/doc/html/rfc8375

[anthonylavado]

Not yet. We will be improving things, the new release was mainly to have at least the most recent version for people with the Homebrew channel.

[anthonylavado]

Fixed in the next release of the app.