Previously we checked that the `request` being sent was an instance of a
PreparedRequest. If a user somehow created a PreparedRequest using a different
Requests library instance, this check makes the request un-sendable.
(This happened recently - unbeknownst to me, my server was running an outdated
version of pip, vulnerable to this issue - pypa/pip#1489, which creates
multiple subdirectories (src/requests, src/requests/requests) when you rerun
pip install --target. So the PreparedRequest was being created in one version
of the library and compared against the other version of the library, and
throwing this exception, even though they were both PreparedRequest instances!)
It would probably be preferable to check the object's behavior (instead of
its type), but a PreparedRequest has a lot of behavior, and it wouldn't be
really feasible or allow us to provide a helpful error message to check all
of it here. Instead flip the conditional to guard against the user sending an
unprepared Request, which should still give us most of the benefits of the
better error message.
Fixes#3102
I only moved the code into a function, there was no actual change to
the code. I added a few tests to ensure we're doing things correctly.
The real point of me doing this is to make it easier to bring back
`strict_mode` functionality. For you requests youngsters in the crowd,
`strict_mode` followed the spec for redirects meaning the method
wouldn't change to a GET. The current code follows the browser
convention of changing the method to a GET when doing a 302 redirect.
However, lots of servers want you to follow the standards (the nerve!)
so I'd like to override the logic. Now that the method changing logic
is in `rebuild_method`, I can simply override that function instead of
overriding the entire `resolve_redirects` function as suggested by
kennethreitz/requests#1325
Prior to this, you could sneak a list of anything to register_hook and it
would accept it. This will check if the items in the list are callable before
registering them. Also added a regression test to make sure if this gets
changed it will be noticed.
Prior to this, you could sneak a list of anything to register_hook and it
would accept it. This will check if the items in the list are callable before
registering them. Also added a regression test to make sure if this gets
changed it will be noticed.
After #831, the tests added in #764 (which relied on iter_content()
crashing if the response was prefetched) no longer tested what they
were intended to test.
This allows iter_content and iter_lines to succeed without
crashing even after the response content has been fetched
(iter_content gives you an iterator over the prefetched
content)
I wasn't thorough enough with how I dealt with headers. Most of the header
logic in the Request object utilizes dictionary properties which will not work
with a key/value list.
I'll dig more into this, but I know the rest of the features are more
important so I'll take my time on this and send a separate pull request.
* Properly handle repeated data fields for multipart/form-data requests (#737)
* Allow a list of 2-tuples as the `files` agument.
* Consistently serialize lists a of parameters (#729).
messense
kennethreitz