gpodder / gpodder

The gPodder podcast client.
http://gpodder.org/
GNU General Public License v3.0
1.28k stars 204 forks source link

Error 'check_hostname requires server_hostname' #1295

Closed BeBiMa closed 2 years ago

BeBiMa commented 2 years ago

Since some days I get the error above, when updating my podcasts in gpodder. Is this an issue known? What can I do?

auouymous commented 2 years ago

That error is caused by using urllib3 1.26 and a proxy with an old urllib3 1.25 schema. How are you configuring your proxy?

BeBiMa commented 2 years ago

I'm using the system settings. Means the proxy of my IPFire router is used. Being urllib3 a python module, why isn't it compatible? Neither the software of the router nor the gpodder installation has changed the last weeks.

BeBiMa commented 2 years ago

Just an excerpt of the log file:

2022-06-02 13:59:47,859 [gpodder.gtkui.main] ERROR: Error: check_hostname requires server_hostname
Traceback (most recent call last):
  File "C:\Program Files (x86)\gPodder\lib\python3.9\site-packages\gpodder\gtkui\main.py", line 2671, in update_feed_cache_proc
    channel.update(max_episodes=self.config.max_episodes_per_feed)
  File "C:\Program Files (x86)\gPodder\lib\python3.9\site-packages\gpodder\model.py", line 1163, in update
    result = self.feed_fetcher.fetch_channel(self, max_episodes)
  File "C:\Program Files (x86)\gPodder\lib\python3.9\site-packages\gpodder\model.py", line 203, in fetch_channel
    return self.fetch(url, channel.http_etag, channel.http_last_modified, max_episodes=max_episodes)
  File "C:\Program Files (x86)\gPodder\lib\python3.9\site-packages\gpodder\feedcore.py", line 181, in fetch
    stream = util.urlopen(url, headers)
  File "C:\Program Files (x86)\gPodder\lib\python3.9\site-packages\gpodder\util.py", line 1208, in urlopen
    return s.get(url, headers=headers, data=data, timeout=timeout, **kwargs)
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/requests/sessions.py", line 555, in get
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/requests/sessions.py", line 542, in request
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/requests/sessions.py", line 655, in send
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/requests/adapters.py", line 439, in send
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/urllib3/connectionpool.py", line 696, in urlopen
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/urllib3/connectionpool.py", line 964, in _prepare_proxy
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/urllib3/connection.py", line 359, in connect
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/urllib3/connection.py", line 500, in _connect_tls_proxy
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/urllib3/util/ssl_.py", line 453, in ssl_wrap_socket
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/site-packages/urllib3/util/ssl_.py", line 495, in _ssl_wrap_socket_impl
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/ssl.py", line 500, in wrap_socket
  File "C:/msys64/home/appveyor/_gpodder_build_root/mingw32/lib/python3.9/ssl.py", line 997, in _create
ValueError: check_hostname requires server_hostname

C:/msys64/ directory doesn't exist on my computer.

auouymous commented 2 years ago

C:/msys64/ directory doesn't exist on my computer.

You don't need to worry about that, it is just where python was located when appveyor built the image.

Being urllib3 a python module, why isn't it compatible?

Urllib3 version 1.26 changed how proxies work and is no longer compatible with the proxies used by previous versions. I don't know why it suddenly broke for you but you need to figure out what proxy URL the router is sending your computer. The URL needs to begin with http:// or https://, the old incompatible proxy URLs did not. Also, some proxies apparently use port 443 with https:// but aren't actually encrypted. If that is the case, you can change the URL to http:// and leave the :443 port, so http://1.2.3.4:443.

BeBiMa commented 2 years ago

Ok, found my error. I've changed my internet options in Windows. 'Use proxy for LAN' was set to my local proxy, but it didn't work really. Deactivated the option, now the system uses the WPAD/PAC file as before. It works again.

Thx nevertheless. Your explanation pointed me to the right direction.