Unknown problem with sessions

I'm using session to POST in a page to login, the problem is, most of time it works, and a few times it doesn't, the response headers comes different even if the request headers are exactly the same.

What should be the problem, that two identical request headers obtain two different responses?

Is it a persistance error on Requests Session?

Here's how I'm using it:

```
 s = requests.Session()
 p=s.post('https://acesso.uol.com.br/login.html', data=pData, verify=False)
```


Almost certainly not.

Firstly, why are you expecting the response headers to be the same? The server is free to change them whenever it likes. Secondly, are you sure you aren't being logged in?


There's two different responses for the exactly same request, when the login is successfully, it returns a specific set-cookie, to estabilish the session.

When it does not returns it, it means that something went wrong, even if the requests headers are the same.

Also, when the set-cookie is not returned, if I try to navigate to a page that you cannot access without beeing logged in with the session, it does not work.

My script is like that:
1.Attempt to login
2.print result (succes or failure)

Then I run it:
python script.py
output>> Success

The script execution stops, then I run it again:
python script.py
output>> Failure

There's no order in the errors, it's random, also the chance of failure is small like 20%.


Right, are you sure you sending the exact same data each time? For example, can you get Wireshark output to see if there's any difference between a succeeding and a failing request?


I had read p.request.headers and p.headers from success and failure requests.
Note that the script isn't modified beetween the executions, I only run it multiple times.

I've edited my post above, I don't know if you have seen it modified, it's more detailed.

I will try to check it with Wireshark, thanks for the tip, and if you have another idea of what it could be, please tell me.


![s4np28j](https://f.cloud.github.com/assets/5435164/1328967/f0e6ae52-350d-11e3-9b3e-3e17901aa6f4.png)

Could you help me analysing this log?
I've put it side a side to comparison.

I see that something wrong happened in the fifth line from the login failure attempt.
As you can see, the length of the first four packets in both are equal.

Could you tell me how to discover what's going wrong exactly?


Ugh, I forgot this would be over SSL. That makes it much harder to work out what's going on. It's pretty confusing behaviour though. Are you in control of the remote webserver?


Unfortunately I'm not.
It's funny because when you use a browser lib instead requests, it always works good.
Is it because urllib browsers handle the deep connection stuff automatically or better than requests?


@BernardoLima It shouldn't be. Requests Sessions are generally excellent at persisting cookies and connections. It would be interesting to see a sample of your code if possible (feel free to remove sensitive information e.g. posted data, usernames, passwords etc.)


@Lukasa , thank you very much for your help.
I've create a test account so if you need, you can test the script.
I've made a few commentaries in the code, if you need anything, please tell me.

If you run over and over again, like ten times, it should has at least one fail attempt.

Here's it:
https://gist.github.com/BernardoLima/e4f7f8018e44f62393a5


@BernardoLima one issue might be that you're setting the `Content-Length` header yourself. That's generally an awful idea. We'll do that for you and do it correctly. You should also _never_ set it on a Session object.

I would also suggest doing this

``` python

data = {
    'user': email,
    'pass': senha,
    'dest': 'REDIR|http://forum.jogos.uol.com.br/vale-tudo_f_57',
    'skin': 'forum-jogos',
    'submit': 'Submit',
}

r = s.post(url, data=data, verify=False)
```

We will handle the urlencoding of everything for you and set the appropriate headers.


I've made those changes, but the problem persists. It's crazy. Sometimes it works, sometimes it doesn't, and the code has done nothing different. I suspect this problem is in the upstream web server, to be quite honest with you. And it's easy enough to work around: just try the credentials again.


@sigmavirus24 , I didn't knew it was automatic, I thought when you used HTTP requests you should specify every detail, thanks for the tip.

@Lukasa, yes, unfortunately I guess that it might be the only option, I'm going to test it in Chrome, maybe it happens there too.

Thanks for the help guys.

> > Edit:
> > Guys, it's defitnely a server problem, it happens also in Chorme, shame on you bad server.