Python aiohttp post request with exact same parameters yields different response than 'requests' request
Question:
I’m migrating a program that’s using requests to using aiohttp but I’ve hit a part of it were the response I get from using aiohttp is different to that from requests.
Function goes like this and tries to login a user to a website.
async def LoginLN(usuario, contraseña, email, url, session):
s = session # aiohttp session
# some stuff and some other requests using the same aiohttp session to get the appropriate cookies for login and up to this part, all responses are OK
r5 = await s.post('https://some-website.com.ar/register-user', headers=headerss5, cookies=cookie_dict, timeout = 140)
texto5 = await r5.text()
# some more stuff
And I get
texto5 = '{"registration_status":"invalid_credentials","user":[]}'
And user doesn’t log in.
If I just replace the r5 definition by keeping every parameter the same to
async def LoginLN(usuario, contraseña, email, url, session):
# some stuff and some other requests using the same aiohttp session to get the appropriate cookies for login and up to this part, all responses are OK
ss = requests.session()
r5 = ss.post('https://some-website.com.ar/register-user', headers=headerss5, cookies = cookie_dict, timeout = 140)
texto5 = r5.text
# some more stuff
The response is the correct one and I’m able to login the user correctly. headerss5 and cookie_dict are usual header and cookie dictionaries.
I’ve wiresharked the two requests and see some differences but don’t know how to further analyze this and even if I did find something I wouldn’t know what to do about it to make aiohttp work properly but any suggestion is welcomed.
requests request
aiohttp request
I’m using windows 10 and:
requests == 2.27.1
aiohttp == 3.8.3
python == 3.10.0
Answers:
I could finally see what was going on. Inspecting both requests (requests vs aiohttp) with mitmproxy I could see that the cookies sent by aiohttp had double quotes added where requests wouldn’t add them generating the different response. Looking into this problem to find an already existing solution I followed the workaround proposed here of putting the cookies explicitly as header.
I’m migrating a program that’s using requests to using aiohttp but I’ve hit a part of it were the response I get from using aiohttp is different to that from requests.
Function goes like this and tries to login a user to a website.
async def LoginLN(usuario, contraseña, email, url, session):
s = session # aiohttp session
# some stuff and some other requests using the same aiohttp session to get the appropriate cookies for login and up to this part, all responses are OK
r5 = await s.post('https://some-website.com.ar/register-user', headers=headerss5, cookies=cookie_dict, timeout = 140)
texto5 = await r5.text()
# some more stuff
And I get
texto5 = '{"registration_status":"invalid_credentials","user":[]}'
And user doesn’t log in.
If I just replace the r5 definition by keeping every parameter the same to
async def LoginLN(usuario, contraseña, email, url, session):
# some stuff and some other requests using the same aiohttp session to get the appropriate cookies for login and up to this part, all responses are OK
ss = requests.session()
r5 = ss.post('https://some-website.com.ar/register-user', headers=headerss5, cookies = cookie_dict, timeout = 140)
texto5 = r5.text
# some more stuff
The response is the correct one and I’m able to login the user correctly. headerss5 and cookie_dict are usual header and cookie dictionaries.
I’ve wiresharked the two requests and see some differences but don’t know how to further analyze this and even if I did find something I wouldn’t know what to do about it to make aiohttp work properly but any suggestion is welcomed.
requests request
aiohttp request
I’m using windows 10 and:
requests == 2.27.1
aiohttp == 3.8.3
python == 3.10.0
I could finally see what was going on. Inspecting both requests (requests vs aiohttp) with mitmproxy I could see that the cookies sent by aiohttp had double quotes added where requests wouldn’t add them generating the different response. Looking into this problem to find an already existing solution I followed the workaround proposed here of putting the cookies explicitly as header.