Mocker doesn't urllib.parse.quote() URLs (requests does)

[Cheaterman]

Everything in the title - I have an URL with a space in it, it's urllib.parse.quote()-ed to %20 by requests but not by requests-mock, resulting in a failed match!

Thanks in advance :-) I could PR this, but I'm first wondering if that's maybe intentional...?

EDIT: (it's quote() not urlencode() haha)

[jamielennox]

I don't think it's intentional, if it works for requests it should work here too. Will try and have a look this week, but if you want to PR it please go ahead.

[jamielennox]

released as 1.9.0

[OrangeDog]

IMO this was a breaking change. Everyone was encoding their paths already, and now they all fail to match.
At minimum, the error message is confusing:

requests_mock.get('http://test/ABC%20123')

requests_mock.exceptions.NoMockAddress: No mock address: GET http://test/ABC%20123

[ktdreyer]

I used to register my URLs like so (with requests-mock 1.8.0):

adapter.register_uri(
    'GET',
    'https://example.com/api/v1/user/coolmanager@example.com',
    json={'id': 123456})

Unfortunately those are registered as encoded now, so they no longer match. I stepped through my tests with pytest's --pdb option and looked at the paths that are set on the requests_mock pytest fixture matchers, like so:

pp([m._path for m in adapter._matchers])     
['/api/v1/products/foobar',
 '/api/v1/user/coolmanager%40example.com',
 '/api/v1/releases']

[ktdreyer]

Requests uses a slightly different quoting mechanism that quotes spaces, but not other characters.

>>> import requests.utils
>>> requests.utils.requote_uri('https://example.com/')
'https://example.com/'
>>> requests.utils.requote_uri('https://example.com/api/user@example.com')
'https://example.com/api/user@example.com'
>>> requests.utils.requote_uri('https://example.com/api/user example.com')
'https://example.com/api/user%20example.com'

Can we revert the current change for now? I've pushed #167

[m-melis]

This broke all our tests too. However, not sure that reverting this is the way to got, but at least the behavior should be identical to requests.

[jamielennox]

Ah - this is in hindsight an obvious break. Very sorry.

Tracking the issue as #170, i'll tag you all but please comment there.