Requests is no longer converting Boolean values in headers to strings

[jidar]

This results in an InvalidHeader error.

For requests 2.10.0:
In [1]: import requests
In [2]: r = requests.get('http://www.google.com', headers={'fake-header':True})
In [3]: r.request.headers
Out[3]: {'fake-header': True, 'Connection': 'keep-alive', 'Accept-Encoding': 'gzip, deflate', 'Accept': '/', 'User-Agent': 'python-requests/2.10.0'}

For requests 2.11.0:
In [1]: import requests
In [2]: r = requests.get('http://www.google.com', headers={'fake-header':True})

InvalidHeader: Header value True must be of type str or bytes, not <type 'bool'>

[Lukasa]

Please see #3477.

[sigmavirus24]

See also #3477, #865. Requests has always documented that headers must be strings. We just didn't enforce it very well. It's also entirely unclear how to appropriately represent True on Python.

[nateprewitt]

@Lukasa @sigmavirus24 It looks like the HISTORY.rst change specifies only integers. Perhaps that should be changed to 'non-string'?

[jidar]

I found all the history after I posted the bug. It would have been nice to have at least included this change in the changelog (the entry lists only integers as being nixed). It would also have been nice to continue supporting python's bools type for True and False at least.

[Lukasa]

@nateprewitt Yes, it should.

@jidar How do we represent True/False as strings? "True"/"False"? Why that over "true"/"false", "1"/"0", or "Yes"/"No"? Requests is simply refusing to guess in this case, and asking that you unambiguously decide what you want to send.

[Lukasa]

I should note that, as far as I know, there are no headers defined that take "True"/"False" or any variation thereof as header field values. There are one or two that can conceptually accept "1"/"0". That makes booleans bad candidates for special casing: we'd be much more likely to special-case datetimes and integers than bools.

[kennethreitz]

It's, you know, none at all! :)

[jidar]

@Lukasa str(value) seems acceptable. No need for special casing anything really. It's what the user is going to be forced to do on their end now anyway.

[Lukasa]

@jidar str(value) is not acceptable, nor is it what anyone will be forced to do. That may work in your case with your data type, but with many data types it will not work and will lead to us emitting bizarre headers that make no sense. For example, consider datetime objects, which print internal representations when str() is called on them.

[sigmavirus24]

@jidar if that's acceptable for you, I'm very happy. You should only ever be treating your headers as strings though. I would not expect any movement on this.