1b08dcc705
When matching URLs both strings are always lowercased to provide case insensitive matching. Whilst this makes sense for the protocol and the host names it does not necessarily hold true for paths and query strings. A byproduct of this is that the lowercased strings are being reported in request_history which makes it harder to verify requests you made. We enable globally and per adapter setting case sensitive matching. This is intended to become the default in future releases. Change-Id: I7bde70a52995ecf31a0eaeff96f2823a1a6682b2 Closes-Bug: #1584008
958 B
958 B
Known Issues
Case Insensitivity
By default matching is done in a completely case insensitive way. This makes sense for the protocol and host components which are defined as insensitive by RFCs however it does not make sense for path.
A byproduct of this is that when using request history the values for path, qs etc are all lowercased as this was what was used to do the matching.
To work around this when building an Adapter or Mocker you do
with requests_mock.mock(case_sensitive=True) as m:
...or you can override the default globally by
requests_mock.mock.case_sensitive = TrueIt is recommended to run the global fix as it is intended that case sensitivity will become the default in future releases.
Note that even with case_sensitive enabled the protocol and netloc of a mock are still matched in a case insensitive way.