The ordering of cookies in the Cookie header are not correct.

## Summery

I found this issue (I am not sure if it is issue though) when I was analyzing requests and responses of a website and tried to imitate them with [requests library](https://github.com/psf/requests) and found that the cookies ordering in the request Cookie header are not as the same as the browser(Chromium and Firefox) manage them.

In my case I am not able to communicate (imitate request of a normal web browser) with the web application because of the ordering of the cookies.


According to [RFC 2109](https://tools.ietf.org/html/rfc2109) that says: 

> If multiple cookies satisfy the criteria above, they are ordered in
   the Cookie header such that those with more specific Path attributes
   precede those with less specific.  Ordering with respect to other
   attributes (e.g., Domain) is unspecified.

they both have same domain (`path=/`) but the `SESSIONID` has the `HttpOnly` attribute so (I guess) it should precedes to be on the Cookie header but the browser always use the `cookie=; SESSIONID=` order.

## Expected Result

Expect [requests](https://github.com/psf/requests) handle the Cookie header as the browser do.

the first GET request and response in chromium
![image](https://user-images.githubusercontent.com/55282537/96265371-3748d180-0fd2-11eb-9fb3-c15573eab56d.png)

the second GET requests and response in chromium
![image](https://user-images.githubusercontent.com/55282537/96265489-5b0c1780-0fd2-11eb-9dff-5ac5f7c8a49c.png)


## Actual Result

```python
from requests import Session

s = Session()

# The first requests without Cookie header
s.get("http://localhost:8000")
# the second request
s.get("http://localhost:8000")
```
first `s.get("http://localhost:8000")`
![image](https://user-images.githubusercontent.com/55282537/96265960-f3a29780-0fd2-11eb-9a9b-d5638ed02e4b.png)

second `s.get("http://localhost:8000")`
![image](https://user-images.githubusercontent.com/55282537/96266038-0f0da280-0fd3-11eb-910d-003c131e16ba.png)


## Reproduction Steps
the following test server can be used to reproduce the steps


```python
from http.server import BaseHTTPRequestHandler, HTTPStatus, HTTPServer


class Handler(BaseHTTPRequestHandler):

    def do_GET(self):
        self.send_response(HTTPStatus.OK)
        self.send_header("Set-Cookie", "cookie=R123006635; path=/")
        self.send_header("Cache-Control", "no-cache")
        self.send_header("Cache-Control", "no-store")
        self.send_header("Pragma", "no-cache")
        self.send_header("Content-Type", "text/html;charset=UTF-8")
        self.send_header("Expires", "Thu, 01 Jan 1970 00:00:00 GMT")
        self.send_header("Set-Cookie",
                         "SESSIONID=8bYxaPf5vNENGOuOXSYMCO1Ee05VmFsouDinyXp1Zg9tpXjXWoDL!-1207423773; path=/; HttpOnly")
        self.send_header("Content-Language", "en-GB")

        self.end_headers()


server_address = ('', 8000)
httpd = HTTPServer(server_address, Handler)
httpd.serve_forever()

```

Client

```python
from requests import Session

s = Session()

# should be used 2 times first time set the cookie on the session obj
s.get("http://localhost:8000")
s.get("http://localhost:8000")
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.9.0"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.24.0"
  },
  "system_ssl": {
    "version": "1010107f"
  },
  "urllib3": {
    "version": "1.25.10"
  },
  "using_pyopenssl": false
}

```
This problem was on python3.7 too.

Thanks for your help in advance.

`HttpOnly` doesn't make a difference in how the cookie should be interpreted in the semantic way that `Path` _can_ (although you're quoting a _very_ old RFC). (Note that by your own quote, nothing else should affect the ordering but `Path`.) If you look at your responses, the browser gets `cookie=` first, then `SESSIONID` while Python's getting the opposite ordering. So we're at least being consistent with order received here. My guess is that they're being returned in the order they're set in the server response, although I'm not intimately familiar with how Python's cookiejar works in this case or how chromium's cookie handling works.

I don't believe this is a bug and there's little evidence pointing towards it being one. Without evidence of a bug, I'm closing this

@sigmavirus24 thanks for looking into this issue. I made a little mistake uploading the wrong screenshot of the requests library case. Both cases were tested with the Reproducing step server code. The actual screenshot is the following one:

First request with Session object
![image](https://user-images.githubusercontent.com/55282537/96274360-45501f80-0fdd-11eb-9f50-c5478d59510c.png)

Second request with Session object
![image](https://user-images.githubusercontent.com/55282537/96274427-56992c00-0fdd-11eb-9781-7731ee4c00d5.png)

As I said the both cases, the one with browser and the requests library, have been tested with the same server code mentioned above and I just uploaded the wrong pictures of the requests library case.

Also I have tested the Server code with Chrome and Firefox too and they both acted like the Chromium browser screenshot indicated. As mentions in the Expected Result, I expect the same behavior of requests library and the browser in cookie handling.

Thanks in advance.

I still don't believe this is a bug because the cookies have equal priority by your own reference

I just edited the test server code that I wrote in the Reproducing Steps and it turns out that the requests library give sort cookies alphabetically and gives more priority to uppercase cookies! (tried `Sessionid` and `sessionid` in the Set-Cookie in server code)

To reiterate - Requests doesn't order these, the standard library does