Requests: Solicitações 2.11: check_header_validity falhou no cabeçalho com valor inteiro

Criado em 8 ago. 2016 · 23Comentários · Fonte: psf/requests

Oi,

Desde as solicitações 2.11, todas as minhas chamadas usando solicitações para o meu aplicativo foram interrompidas. Após a depuração, parece que esta versão não aceita cabeçalho com valor inteiro, como era antes.

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'>

Nós definimos 'Content-Length' em cada solicitação. De qualquer forma, usar um inteiro para um cabeçalho que semanticamente é um inteiro faz sentido, não?

Fonte

lmazuel

Comentários muito úteis

Parece uma mudança significativa para um lançamento pontual, não?

clarkbreyman-yammer em 8 ago. 2016

👍25

Todos 23 comentários

Infelizmente, não-strings para valores de cabeçalho nunca foi uma maneira aceita de usar Requests e, embora fosse permitido em versões anteriores, desde então fizemos alterações que não permitiam isso. Isso ocorre principalmente porque os cabeçalhos são _realmente_ mapeamentos de string-string, mas também porque a abordagem geral de chamar str em itens que são passados para Requests tende a se comportar mal de maneiras inesperadas que surpreendem os usuários.

O TL; DR disso é: sim, isso foi feito de propósito e não, não achamos que seja um bug.

Lukasa em 8 ago. 2016

Veja também: # 865.

Lukasa em 8 ago. 2016

Parece uma mudança significativa para um lançamento pontual, não?

clarkbreyman-yammer em 8 ago. 2016

👍25

E você não descreveu essa grande modificação no ChangeLog :(

lmazuel em 8 ago. 2016

Esta não é uma alteração significativa da API - a API é claramente documentada como sendo baseada em string, em toda a documentação. O fato de você estar usando-o com inteiros, em vez de sua entrada pretendida, é um bug em seu código, não com esta base de código ou uma mudança na API.

Adicionar uma nota no changelog sobre essa mudança ininterrupta pode ser uma boa ideia.

kennethreitz42 em 8 ago. 2016

@ clarkbreyman-yammer Para ser claro, este é um caso um tanto limítrofe. Você pode ver a tomada de decisão mais recentemente em # 3386 e # 3388, mas o argumento básico é: cabeçalhos sem string nunca foram _intencionados_ a funcionar, então o fato de que pararam de funcionar é aceitável. Na verdade, isso não funcionou anteriormente.

@lmazuel Você está certo de que isso passou despercebido no log de mudanças, e isso é 100% minha culpa: a quebra aqui foi acidental de nossa verificação mais rigorosa dos valores do cabeçalho e, como resultado, não vi isso quando estava compilando o changelog. Eu agradeceria um PR que atualize o changelog se você quiser fazer um.

Lukasa em 8 ago. 2016

E para ser claro, nós três estamos de acordo sobre isso. O fato de enviar um inteiro para lá _nunca_ funcionou foi pura sorte. Costumava não funcionar e decidimos que nunca deveria funcionar há muito tempo. Nunca tivemos nada que _forçasse_ isso.

sigmavirus24 em 8 ago. 2016

Dito isso, adicionar isso como um recurso com suporte é potencialmente uma grande ideia e seria uma mudança de API bem-vinda no meu livro (se a implementação foi bem feita). No entanto, o estado atual das coisas provavelmente permanecerá por um longo futuro.

kennethreitz42 em 8 ago. 2016

Adicionada uma nota no changelog.

kennethreitz42 em 8 ago. 2016

Obrigado @kennethreitz.

Lukasa em 8 ago. 2016

Ok, obrigado pelo esclarecimento. Vou atualizar meu código de acordo.
@kennethreitz se você pudesse adicionar sua nota no PyPI também, seria incrível.

lmazuel em 8 ago. 2016

@lmazuel nisso!

kennethreitz42 em 8 ago. 2016

@lmazuel done ✨🍰✨

kennethreitz42 em 8 ago. 2016

🎉3 👍2

@lmazuel ps obrigado pelo carinho: P

kennethreitz42 em 8 ago. 2016

👍1

Eu consertei meu código, todo o resto está funcionando muito bem. Obrigado pelo seu tempo de resposta ultrarrápido!

lmazuel em 9 ago. 2016

nas documentações oficiais não há menção sobre a grande mudança. É realmente enganoso.

COLDMOUNT em 26 set. 2016

Não é considerada uma grande mudança pela equipe de solicitações, é considerada uma correção de bug que se encaixa nos limites do comportamento da biblioteca documentada.

Lukasa em 26 set. 2016

Olá @COLDMOUNT , você pode encontrar a documentação aqui no último parágrafo da seção de início rápido para cabeçalhos personalizados. Também publicamos a mudança em HISTORY.rst para 2.11.0 que é o changelog de Requests.

nateprewitt em 26 set. 2016

É melhor oferecer um exemplo de cabeçalhos no tipo str, ou como
traduzir os cabeçalhos do tipo dict para o tipo str, obrigado.

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

Olá @COLDMOUNT https://github.com/COLDMOUNT , você pode encontrar o
documentação aqui
http://docs.python-requests.org/en/master/user/quickstart/#custom -headers
no último parágrafo da seção de início rápido para cabeçalhos personalizados. Nós
também publicou a mudança em (HISTORY.rst) [ https: // github.
com / kennethreitz / requests / blob / master / HISTORY.rst] para 2.11.0 que é
Changelog de solicitações.
-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3477#issuecomment -249638650,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ARIa89wU7tKL8Br2WWU6lJy8HEbNr72Vks5quAE3gaJpZM4JffFG
.

COLDMOUNT em 27 set. 2016

ou como traduzir cabeçalhos de um tipo de dicionário para o tipo de str

Espere o que? Como você estava enviando cabeçalhos antes?

Lukasa em 27 set. 2016

Assim como o guia na página -
http://docs.python-requests.org/en/master/user/quickstart/ - "Se você
gostaria de adicionar cabeçalhos HTTP a uma solicitação, basta passar um dict para os cabeçalhos
parâmetro. "Mas agora o tipo de dict não é mais aceito, e o que significa str
tipo se parece?

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

ou como traduzir cabeçalhos de um tipo de dicionário para o tipo de str
Espere o que? Como você estava enviando cabeçalhos antes?
-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3477#issuecomment -249819028,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ARIa8_ZPJmzxH2lWmpTvSJ3PvHE7jlpvks5quOcrgaJpZM4JffFG
.

COLDMOUNT em 27 set. 2016

@COLDMOUNT dict é _absolutamente_ aceito, não mudamos nada. O que mudamos é que as chaves e valores desse dict agora devem ser strings. Anteriormente, era possível que fossem alguns outros tipos por acidente, o que agora foi resolvido. A documentação não precisa ser alterada.

Lukasa em 27 set. 2016

Entendi, legal! Obrigado! :)

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

@COLDMOUNT https://github.com/COLDMOUNT dict é _absolutamente_ aceito,
nós não mudamos isso de forma alguma. O que mudamos é que as chaves e
os valores desse dict agora devem ser strings. Anteriormente, era possível para
eles são alguns outros tipos por acidente, o que agora foi resolvido. o
a documentação não precisa ser alterada.
-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kennethreitz/requests/issues/3477#issuecomment -249825918,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ARIa8z0jZ-ovBtvFWl4hTXnkk_kJXobrks5quO6ggaJpZM4JffFG
.