-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated address normalization to test for https first to fix #223 #233
Conversation
I don't think the fallback to http is working. Particularly if you have a reverse proxy where some have ssl and some don't. At least with nginx, it ends up defaulting to using a different certificate since the request came in over 443.
|
That fixes the error I saw. I wonder if we should put an extra log message or two in. Along the lines of "Attempting secure connection" and "Falling back to insecure http" otherwise users are likely to just see a connection error in the logs and send issues. It's kinda like the libraries error that gets thrown up on a fresh install. Thoughts? |
Actually, I think I have a cleaner way. jellyfin-kodi/jellyfin_kodi/jellyfin/api.py Lines 431 to 433 in 011186e
Instead of immediately returning the response here, we could do something involving the def get_public_info(self, server_address):
response = self.send_request(server_address, "system/info/public")
if response.history:
if response.history[0].response_code == 301
# make new request with https
return response.json() if response.status_code == 200 else {} We'll probably have to adjust the response so that the |
The addon would still store the address as https with this method though. Using the current implementation it changes the stored url. Also that won't catch the ssl errors we've seen |
Yes, that's part of the "adjust the response so the I don't like the idea of forcing https first and throwing errors. We've been trying to get rid of the needless errors in the logs, plus it feels too much like using try/except for program flow. |
Resolves #223 where the http->https redirect was causing the server to not respond properly. This changes the default to try HTTPS first, then if that is not available goes down to http