Requests: les plantages de chaîne d'url inhabituels sont py3

Pour la postérité, la trace complète est celle-ci :

>>> requests.get(base_url)
Traceback (most recent call last):
  File "/Users/cory/.pyenv/versions/3.6.0/lib/python3.6/encodings/idna.py", line 165, in encode
    raise UnicodeError("label empty or too long")
UnicodeError: label empty or too long

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/cory/Documents/Python/requests_org/requests/requests/api.py", line 72, in get
    return request('get', url, params=params, **kwargs)
  File "/Users/cory/Documents/Python/requests_org/requests/requests/api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "/Users/cory/Documents/Python/requests_org/requests/requests/sessions.py", line 493, in request
    prep.url, proxies, stream, verify, cert
  File "/Users/cory/Documents/Python/requests_org/requests/requests/sessions.py", line 666, in merge_environment_settings
    env_proxies = get_environ_proxies(url, no_proxy=no_proxy)
  File "/Users/cory/Documents/Python/requests_org/requests/requests/utils.py", line 692, in get_environ_proxies
    if should_bypass_proxies(url, no_proxy=no_proxy):
  File "/Users/cory/Documents/Python/requests_org/requests/requests/utils.py", line 676, in should_bypass_proxies
    bypass = proxy_bypass(netloc)
  File "/Users/cory/.pyenv/versions/3.6.0/lib/python3.6/urllib/request.py", line 2616, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/Users/cory/.pyenv/versions/3.6.0/lib/python3.6/urllib/request.py", line 2593, in proxy_bypass_macosx_sysconf
    return _proxy_bypass_macosx_sysconf(host, proxy_settings)
  File "/Users/cory/.pyenv/versions/3.6.0/lib/python3.6/urllib/request.py", line 2566, in _proxy_bypass_macosx_sysconf
    hostIP = socket.gethostbyname(hostonly)
UnicodeError: encoding with 'idna' codec failed (UnicodeError: label empty or too long)

Je ne pense pas que nous puissions faire grand-chose à ce sujet. L'erreur provient de la bibliothèque standard (en particulier, dans la fonction urllib proxy_bypass ). Il n'est présent que sur Python 3, qui ressent le besoin d'appeler socket.gethostbyname . Cette fonction encodera automatiquement par IDNA un nom d'hôte Unicode, même dans des situations comme celle-ci où ce n'est tout simplement pas nécessaire, et son encodeur IDNA le rejette correctement.

La seule façon de résoudre ce problème est de passer à une implémentation de gestion des URL beaucoup plus intelligente qui normalise les URL sous une forme ou une autre. Le meilleur candidat est le lien hypertexte, mais le lien hypertexte vomit également pour une raison similaire (il essaie de coder l'IDNA et échoue).

Cela signifie qu'au mieux , nous pourrions résoudre ce problème en étendant le lien hypertexte avec un normalisateur d'hôte d'URL, puis le gérer. Cependant, la spécification d'URL WHATWG semble également interdire cette forme d'URL. Si c'est le cas, je ne sais pas pourquoi, car Chrome le normalise (bien que Safari ne le fasse pas).

Compte tenu de la quantité de travail nécessaire pour le faire, je ne vois aucune raison de le tolérer. L'URL est juste spectaculairement loin de tout ce qui peut raisonnablement fonctionner, donc je suis enclin à fermer cela car cela ne résoudra pas.

Je rencontre ceci pour une URL du format :

https://key:[email protected]/path/file.json

et longueur de 132 caractères.

@johnpaulhayes Ce n'est toujours pas un problème avec la bibliothèque de requêtes, mais comme je le rencontre également, je pense que je vais déposer une mise à jour.

Ce n'est pas la longueur totale de l'URL qui semble le faire, juste une section de celle-ci. L'encodeur idna semble se casser sur les URL lorsque la première partie du nom d'hôte est supérieure à 64 caractères. Pour une raison quelconque, cela inclut également la clé et le secret. Donc, évitez python3 ou évitez les longues chaînes " key:secret@example " (probablement en évitant les longues clés api) jusqu'à ce que les fonctions sous-jacentes soient corrigées. J'ai soumis un bogue pour cela au traqueur python hier.

Pour ceux que la question intéresse côté python
https://bugs.python.org/issue32958