Requests: Requêtes 2.11 : échec de check_header_validity sur l'en-tête avec une valeur entière

Créé le 8 août 2016 · 23Commentaires · Source: psf/requests

Salut,

Depuis les requêtes 2.11, tous mes appels utilisant des requêtes pour mon application sont interrompus. Après débogage, il semble que cette version n'accepte pas les en-têtes avec une valeur entière, comme c'était le cas auparavant.

2.10 :

In [1]: import requests

In [2]: requests.get('http://bing.com', headers={'Content-Length': 42})
Out[2]: <Response [200]>

2.11

In [1]: import requests

In [2]: requests.get('http://bing.com', headers={'Content-Length': 42})
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
D:\VSProjects\azure-sdk-for-python\env3.5\Lib\site-packages\requests\utils.py in check_header_validity(header)
    751     try:
--> 752         if not pat.match(value):
    753             raise InvalidHeader("Invalid return character or leading space in header: %s" % name)

TypeError: expected string or bytes-like object

During handling of the above exception, another exception occurred:

InvalidHeader                             Traceback (most recent call last)
<ipython-input-2-ae7ec2933e34> in <module>()
----> 1 requests.get('http://bing.com', headers={'Content-Length': 42})

D:\VSProjects\azure-sdk-for-python\env3.5\Lib\site-packages\requests\api.py in get(url, params, **kwargs)
     68
     69     kwargs.setdefault('allow_redirects', True)
---> 70     return request('get', url, params=params, **kwargs)
     71
     72

D:\VSProjects\azure-sdk-for-python\env3.5\Lib\site-packages\requests\api.py in request(method, url, **kwargs)
     54     # cases, and look like a memory leak in others.
     55     with sessions.Session() as session:
---> 56         return session.request(method=method, url=url, **kwargs)
     57
     58

D:\VSProjects\azure-sdk-for-python\env3.5\Lib\site-packages\requests\sessions.py in request(self, method, url, params, data, headers, cookies, files, auth, timeout, allow_redirects, proxies, hooks, stream, verify, cert, json)
    455             hooks = hooks,
    456         )
--> 457         prep = self.prepare_request(req)
    458
    459         proxies = proxies or {}

D:\VSProjects\azure-sdk-for-python\env3.5\Lib\site-packages\requests\sessions.py in prepare_request(self, request)
    388             auth=merge_setting(auth, self.auth),
    389             cookies=merged_cookies,
--> 390             hooks=merge_hooks(request.hooks, self.hooks),
    391         )
    392         return p

D:\VSProjects\azure-sdk-for-python\env3.5\Lib\site-packages\requests\models.py in prepare(self, method, url, headers, files, data, params, auth, cookies, hooks, json)
    293         self.prepare_method(method)
    294         self.prepare_url(url, params)
--> 295         self.prepare_headers(headers)
    296         self.prepare_cookies(cookies)
    297         self.prepare_body(data, files, json)

D:\VSProjects\azure-sdk-for-python\env3.5\Lib\site-packages\requests\models.py in prepare_headers(self, headers)
    407             for header in headers.items():
    408                 # Raise exception on invalid header value.
--> 409                 check_header_validity(header)
    410                 name, value = header
    411                 self.headers[to_native_string(name)] = value

D:\VSProjects\azure-sdk-for-python\env3.5\Lib\site-packages\requests\utils.py in check_header_validity(header)
    754     except TypeError:
    755         raise InvalidHeader("Header value %s must be of type str or bytes, "
--> 756                             "not %s" % (value, type(value)))
    757
    758

InvalidHeader: Header value 42 must be of type str or bytes, not <class 'int'>

Nous définissons 'Content-Length' dans chaque requête. Quoi qu'il en soit, utiliser un entier pour un en-tête qui est sémantiquement un entier a du sens non?

Source

lmazuel

Commentaire le plus utile

Cela ressemble à un changement radical pour une libération de points, non ?

clarkbreyman-yammer le 8 août 2016

👍25

Tous les 23 commentaires

Les non-chaînes pour les valeurs d'en-tête n'ont jamais été un moyen accepté d'utiliser les requêtes, malheureusement, et alors que cela était autorisé dans les versions précédentes, nous avons depuis apporté des modifications qui l'interdisent. C'est principalement parce que les en-têtes sont _vraiment_ des mappages de chaînes de caractères, mais aussi parce que l'approche générale consistant à appeler str sur des éléments transmis à Requests a tendance à mal se comporter de manière inattendue qui surprend les utilisateurs.

Le TL;DR de ceci est : oui, cela a été fait exprès, et non, nous ne pensons pas que ce soit un bug.

Lukasa le 8 août 2016

Voir aussi : #865.

Lukasa le 8 août 2016

Cela ressemble à un changement radical pour une libération de points, non ?

clarkbreyman-yammer le 8 août 2016

👍25

Et vous n'avez pas décrit cette énorme modification dans le ChangeLog :(

lmazuel le 8 août 2016

Il ne s'agit pas d'un changement d'API de rupture — l'API est clairement documentée comme étant basée sur des chaînes, tout au long de la documentation. Le fait que vous l'utilisiez avec des entiers, au lieu de son entrée prévue, est un bogue dans votre code, pas dans cette base de code ou un changement dans l'API.

L'ajout d'une note dans le journal des modifications à propos de ce changement permanent peut être une bonne idée.

kennethreitz42 le 8 août 2016

@clarkbreyman-yammer Pour être clair, c'est un peu un cas limite. Vous pouvez voir la prise de décision la plus récente dans #3386 et #3388, mais l'argument de base est le suivant : les en-têtes non-chaîne n'ont jamais été destinés à fonctionner, donc le fait qu'ils aient cessé de fonctionner est acceptable. En fait, cela n'a pas fonctionné auparavant dans le passé.

@lmazuel Vous avez raison de dire que cela a été manqué dans le

Lukasa le 8 août 2016

Et pour être clair, nous sommes tous les trois d'accord sur ce point. Le fait que l'envoi d'un entier là-bas ait jamais fonctionné était purement chanceux. Cela ne fonctionnait pas du tout et nous avons décidé que cela ne devrait jamais fonctionner il y a longtemps. Nous n'avons jamais rien eu qui _enforce_ cela cependant.

sigmavirus24 le 8 août 2016

Cela étant dit, ajouter qu'en tant que fonctionnalité prise en charge est potentiellement une excellente idée et serait un changement d'API bienvenu dans mon livre (si l'implémentation a été bien faite). Cependant, l'état actuel des choses est susceptible de rester dans un avenir prolongé.

kennethreitz42 le 8 août 2016

Ajout d'une note dans le changelog.

kennethreitz42 le 8 août 2016

Merci @kennethreitz.

Lukasa le 8 août 2016

D'accord, merci pour la précision. Je mettrai à jour mon code en conséquence.
@kennethreitz si vous pouviez également ajouter votre note dans PyPI, ce serait incroyable.

lmazuel le 8 août 2016

@lmazuel dessus !

kennethreitz42 le 8 août 2016

@lmazuel terminé

kennethreitz42 le 8 août 2016

🎉3 👍2

@lmazuel ps merci de votre attention :P

kennethreitz42 le 8 août 2016

👍1

J'ai corrigé mon code, tout le reste fonctionne très bien. Merci pour votre temps de réponse ultra rapide !

lmazuel le 9 août 2016

dans les documentations officielles, il n'y a aucune mention du changement majeur. C'est vraiment trompeur.

COLDMOUNT le 26 sept. 2016

Ce n'est pas considéré comme un changement majeur par l'équipe des demandes, c'est considéré comme une correction de bogue qui s'inscrit dans les limites du comportement de la bibliothèque documentée.

Lukasa le 26 sept. 2016

Hé @COLDMOUNT , vous pouvez trouver la documentation ici dans le dernier paragraphe de la section de démarrage rapide pour les en-têtes personnalisés. Nous avons également publié le changement dans HISTORY.rst pour 2.11.0 qui est le changelog de Requests.

nateprewitt le 26 sept. 2016

Il est préférable de proposer un exemple des en-têtes de type str, ou comment
traduire un en-tête de type dict en type str, merci.

2016-09-27 1:30 GMT+08:00 Nate Prewitt [email protected] :

Hé @COLDMOUNT https://github.com/COLDMOUNT , vous pouvez trouver le
documentation ici
http://docs.python-requests.org/en/master/user/quickstart/#custom -headers
dans le dernier paragraphe de la section de démarrage rapide pour les en-têtes personnalisés. Nous
a également publié le changement dans (HISTORY.rst)[ https://github.
com/kennethreitz/requests/blob/master/HISTORY.rst] pour 2.11.0 qui est
Changelog des requêtes.
-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3477#issuecomment-249638650 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ARIa89wU7tKL8Br2WWU6lJy8HEbNr72Vks5quAE3gaJpZM4JffFG
.

COLDMOUNT le 27 sept. 2016

ou comment traduire un en-tête de type dict en type str

Attends quoi? Comment envoyiez-vous les en-têtes avant ?

Lukasa le 27 sept. 2016

Tout comme le guide sur la page --
http://docs.python-requests.org/en/master/user/quickstart/ -- "Si vous vouliez
comme ajouter des en-têtes HTTP à une requête, passez simplement un dict aux en-têtes
paramètre." Mais maintenant, le type dict n'est plus accepté, et qu'est-ce que le str
type ressembler?

27/09/2016 17:51 GMT+08:00 Cory Benfield [email protected] :

ou comment traduire un en-tête de type dict en type str
Attends quoi? Comment envoyiez-vous les en-têtes avant ?
-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3477#issuecomment-249819028 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ARIa8_ZPJmzxH2lWmpTvSJ3PvHE7jlpvks5quOcrgaJpZM4JffFG
.

COLDMOUNT le 27 sept. 2016

@COLDMOUNT dict est _absolument_ accepté, nous n'avons rien changé du tout. Ce que nous avons changé, c'est que les clés et les valeurs de ce dict doivent maintenant être des chaînes. Auparavant, il était possible qu'ils soient quelques autres types par accident, ce qui a maintenant été résolu. La documentation n'a pas besoin d'être modifiée.

Lukasa le 27 sept. 2016

Compris, cool ! Merci! :)

2016-09-27 18:23 GMT+08:00 Cory Benfield [email protected] :

@COLDMOUNT https://github.com/COLDMOUNT dict est _absolument_ accepté,
nous n'avons rien changé du tout. Ce que nous avons changé, c'est que les clés et
les valeurs de ce dict doivent maintenant être des chaînes. Auparavant, il était possible pour
eux pour être quelques autres types par accident, qui a maintenant été résolu. Les
la documentation n'a pas besoin d'être modifiée.
-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kennethreitz/requests/issues/3477#issuecomment -249825918,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ARIa8z0jZ-ovBtvFWl4hTXnkk_kJXobrks5quO6ggaJpZM4JffFG
.