Hi all,
I recently weeded out the ciphers offered by the loadbalancer.
If i disable all but tls1.3, the "autodiscovery" requests to /deovr fail with handshake errors.
The component doing the request to /deovr seems to be something different then the browsers network engine ((lib)curl?)
first, the browser is totally fine with tls1.3 only and second, the requests to /deovr are HTTP/1.1 requests, if the magic /deovr "autodiscovery" does the request.
Otherwise all other (real) deovr-browser-requests made to the site - even for /deovr - are HTTP/2 (if it's ALPN offered, of course)
serving json files conforming to the standard did never work for me. Does this only work if it's a button or <a with the double protocol thingi deovr://https:/// so it's "user-initiated"? Can i redirect to such a double-protocol url?
Serving the json directly to the browser just make it render it as text/plain (it has the correct content-type)
could you add basic .m3u support? would be much easier in some instances.
Is there a specific reason why you escape the "/" in the urls in the jsons you deliver?
it's unneeded according to rfc8259 and works fine without out. Taking a "jq reparse" as ground truth: it removes the quoting of "/" as well.
could you add "videoUrl" as an alias for "video_url" and perhaps deprecate "video_url"? it's the only thing written in snake_case, all other field-names are camelCased
Cheers
Benedikt
