This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients christian.heimes, orsenthil, pmenzel
Date 2020-06-16.07:36:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1592293019.05.0.999036176711.issue40968@roundup.psfhosted.org>
In-reply-to
Content
It looks like the server is refusing requests that don't have an ALPN extension set in TLS layer. At first I though that the server may only support HTTP/2. The curl requests in your examples uses HTTP/2. urllib only supports HTTP/1.1 and HTTP/1.0.

Then I tried "curl --http1.1 https://jitsi.molgen.mpg.de". The request also succeeds because curl is sending "ALPN, offering http/1.1".

This request works for me:

>>> import ssl
>>> import urllib.request
>>> ctx = ssl.create_default_context()
>>> ctx.set_alpn_protocols(['http/1.1'])
>>> urllib.request.urlopen('https://jitsi.molgen.mpg.de', context=ctx)
<http.client.HTTPResponse object at 0x6040009b7960>

urllib could set the ALPN header by default when the user does not supply a custom context. It looks like curl always adds an ALPN extension. I don't see code in Python requests that sets ALPN extension. On the other hand Tom Christie's excellent httpx library does set ALPN extension just like curl.
History
Date User Action Args
2020-06-16 07:36:59christian.heimessetrecipients: + christian.heimes, orsenthil, pmenzel
2020-06-16 07:36:59christian.heimessetmessageid: <1592293019.05.0.999036176711.issue40968@roundup.psfhosted.org>
2020-06-16 07:36:59christian.heimeslinkissue40968 messages
2020-06-16 07:36:58christian.heimescreate