Raibek/requests-github-issues huggingface dataset:
CI: bump actions version

## Changes

- Bump `actions/checkout` from `v2` (Node 12) to `v3` (Node 16). [This will fix the node 12 deprecation warnings in action runs]
- Bump `actions/setup-python` to `v4`.
- Bump `dessant/lock-threads` to `v4`.
- Bump codeql actions to `v2`.

Thanks for the PR @kbdharun. This got moved to strict pins and automated with dependabot to hopefully avoid manual patches going forward. We'll close this out since the underlying issue has been resolved.

> Thanks for the PR @kbdharun. This got moved to strict pins and automated with dependabot to hopefully avoid manual patches going forward. We'll close this out since the underlying issue has been resolved.

Great, Setting Dependabot is indeed better for things like this.
cannot import name 'DEFAULT_CIPHERS'

<!-- Summary. -->
With the release of requests==2.3.0 it looks like it's pulling down urllib3==2.0.1, when trying to import requests on an aws lambda (python 3.9  manylinux_2_24_x86_64) I am getting:

[ERROR] Runtime.ImportModuleError: Unable to import module 'myapp': cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_' (/opt/python/urllib3/util/ssl_.py)

If it at all is important, requests is stored in a lambda layer.

## Reproduction Steps

Create a python3.9 AWS lambda:
```
import boto3
import requests

def lambda_handler(event, context):
    print(event)
    return None
```

Create a folder commonlib/python
Create packages in it
```
requests==2.3.0
```

pip install --quiet --upgrade -r commonlibs/python/packages -t commonlibs/python --only-binary=:all: --platform manylinux_2_24_x86_64

zip it up add it as a layer to aws
attach the layer to your lambda 
test the lambda
[ERROR] Runtime.ImportModuleError: Unable to import module 'myapp': cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_' (/opt/python/urllib3/util/ssl_.py)

## System Information

python version: 3.9
os: amazon linux 2 manylinux_2_24_x86_64


Hi @rasperin,

This isn't an issue with Requests, but with the version of botocore (A dependency of boto3 which currently doesn't explicitly support urllib3 2.0) being used. It looks like you've installed incompatible dependencies in your Lambda which is leading to the error you're seeing.

This was already fixed in the latest release of Botocore with https://github.com/boto/botocore/pull/2924, so you can either upgrade boto3 or provide an older version of urllib3 in your package.

Confirmed, sorry about that. 

No worries! Glad you got it sorted. I'll go ahead and resolve this then.
v2.30.0

2.30.0 (2023-05-03)
-------------------

**Dependencies**
- ⚠️ Added support for urllib3 2.0. ⚠️

  This may contain minor breaking changes so we advise careful testing and
  reviewing https://urllib3.readthedocs.io/en/latest/v2-migration-guide.html
  prior to upgrading.

  Users who wish to stay on urllib3 1.x can pin to `urllib3<2`.
cannot use request.get when there is "//" in url

I'm using FastAPI to request the status of my robot, and I'm also using my fleet manager to request its status. However, I encountered an error that says 'Cannot mix str and non-str argument' when my URL is constructed as follows:
url = 'http://' + str(self.robot_ip[robot_name]) + ':' + str('5000') + '/status/'
I deduced that this may be because of the double forward slashes (//) following http:
How to fix or could you recommend me other API

Your deduction is wholly incorrect. Without additional information which you haven't provided, we can't help you.

Please use [StackOverflow](https://stackoverflow.com) for general usage questions instead and only report defects here.
GBK Encoding Error

<!-- Summary. -->

I encounter an encoding error when use requests to send request (method:post&get).

## Expected Result

<!-- What you expected. -->
![image](https://user-images.githubusercontent.com/30283620/234916977-b17da668-9e72-469a-bae2-ad7c75dc13cf.png)

## Actual Result

<!-- What happened instead. -->

![image](https://user-images.githubusercontent.com/30283620/234920176-2017d8be-a855-44f0-a7a2-39ae9a169528.png)

![image](https://user-images.githubusercontent.com/30283620/234916387-7ce65506-ddad-44d7-a014-0ae23cd15445.png)

The return text is wrong.
Exactly, the ret.content is wrong, too.
I think the error happens when reading content.

## Reproduction Steps

```python
import requests
print(requests.post(url, params={'method':'pageInfo'}, data={'queryString':queryString}).text)
# Note: My URL is a local area network website, and it send data with gbk encoding.
```

## System Information

    $ python -m requests.help

```json
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "2.1.1"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.4"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.11.1"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.29.0"
  },
  "system_ssl": {
    "version": "1010111f"
  },
  "urllib3": {
    "version": "1.26.13"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}
```

<!-- This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c). -->


`Response.content` is the exact bytes we read off the wire, it has no encoding applied.

You might check whether the payload is gzip compressed. Other than that though, Requests cannot affect what the server returns. If you're getting back unexpected bytes, it may be the server attempting to limit web scraping or a misconfiguration. We won't be able to help with that unfortunately.
Add global SSL/TLS configuration options via environment variable

Hello,

I would like to request a feature to allow setting SSL/TLS options globally in the requests library via an environment variable or a configuration file. Currently, while the requests library has the ability to set the correct version of TLS, it's not possible to change it globally via environment variable.

This feature is important for users who need to configure SSL/TLS options for their entire environment, rather than on a per-application basis. This would help avoid issues caused by outdated or unsupported SSL/TLS protocols and provide users with more flexibility in configuring their SSL/TLS settings.

This issue was recently highlighted in a feature request for pip (https://github.com/pypa/pip/issues/11896), which attempted to add a command-line option to disable unsafe legacy renegotiation and enforce the use of TLS 1.3. However, this option was deemed better suited for the requests library.

Therefore, I would like to propose adding a means to set SSL/TLS options globally in the requests library, for example via an environment variable.

Thank you for your attention to this matter, and please let me know if you have any questions or feedback.

Best regards,
Andrej Zachar

As was clearly laid out in that issue, this library is in feature freeze.

Further, environment variables supported by this library already, intended to be used to give customers a way to improve their security posture have instead created vulnerabilities that are near impossible to completely remediate. Additional environment variables - especially ones that affect TLS connections - that may affect everything running with those settings are yet another attack venue. So beyond being something we wouldn't do due to the feature freeze, it's also something I wouldn't ever support because of the impact it could have on many users' security posture without them understanding it's severity.
v2.29.0

2.29.0 (2023-04-26)
-------------------

**Improvements**

- Requests now defers chunked requests to the urllib3 implementation to improve
  standardization. (#6226)
- Requests relaxes header component requirements to support bytes/str subclasses. (#6356)

@nateprewitt Did we want to change the version ranges allowed for urllib3 to allow 2.0.0 without a warning? I figure this is safe now that urllib3 integration test suite passes w/ requests without any patches.

Ideally, I think we would leave the pin in place to minimize blast radius. We _shouldn't_ break now that the chunking is merged if users are forcibly upgrading outside the supported range. After we get some prime time with the major version bump, I'm fine cutting another minor version to expand support. I just don't want to opt people into a major version bump without warning.

Thank you!
Event-stream response encoding should be detected as utf-8

When from an event stream, requests detects the encoding as being ISO-8859-1, which can leads to improper character decoding if that information is used. 
It seems that event stream should always be encoded with utf-8 according to https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream, so the response encoding information should probably be set to utf-8 when the content-type is text/event-stream

## Expected Result

The encoding should be detected as being utf-8

## Actual Result

The encoding is detected as ISO-8859-1, probably because of this code https://github.com/psf/requests/blob/51716c4ef390136b0d4b800ec7665dd5503e64fc/requests/utils.py#L555 and the presence of the `text` in the content-type.


Hi @yannrouillard, Event Streams are an HTML specification from WHATWG, not an http specification. Requests is not a browser and will likely never support the full range of behaviors built on top of HTTP.

This should be relatively straight forward to solve for any project using Requests. You can either directly set the `encoding` on the Response before calling `text` to avoid guessing, or the server can supply `; charset=utf-8` on the end of the Content-Type to explicitly define this behavior.

Thanks for the answer @nateprewitt.

In that case, it may have been nicer to not return 'ISO-8859-1' encoding since the encoding was, in fact, not known, but I see this is already the subject of existing issue https://github.com/psf/requests/issues/2086 and not a simple issue.
chore(charset issue): Resolution for issue 6102 

Resolution for the issue https://github.com/psf/requests/issues/6102

Now, If a username and password are passed already encoded, they will not be affected by being expected as a string. In this case, the function will encode the string-formatted attributes into bytes using the latin-1 charset by default due to convention.

Hi, @sigmavirus24 

Thank you for your explanation in my last PR (https://github.com/psf/requests/pull/6422), and you were right. My last PR didn't solve the issue/bug. However, I believe that this PR resolves the bug.

Could you please review the PR and let me know if it's okay?

Respectfully,
pin cryptography<40 on pypy 3.7

Fixes https://github.com/psf/requests/issues/6419

PyPy 3.7 is no longer receiving updates, are you willing to drop it?

~~I think we're going to wait until at least June before we get rid of 3.7. Given the adoption level though, we'll likely give 3-6 months of migration time before we fully drop support.~~

~~Is urllib3 moving in that direction sooner?~~

Sorry misread original comment. We'll move PyPy testing to 3.9 next but that's likely still a few months down the road.
pypy 3.7 CI build failing

pypy 3.7 fails with a core dump:

```
Fatal Python error: Aborted

Stack (most recent call first, approximate line numbers):
  File "<frozen importlib._bootstrap>", line 220 in _call_with_frames_removed
make: *** [Makefile:8: ci] Aborted (core dumped)
```

Looks like it's failing due to the trustme import in the nosan_server fixture
github actions on ubuntu 18.04 fail to start because the image was removed

github actions on ubuntu 18.04 fail to start because the image was removed: https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/

this might be a challenge because the tests fail with SSLError: https://github.com/psf/requests/issues/5662

Resolved in #6418
reenable the warnings plugin

The warnings plugin was disabled in https://github.com/psf/requests/pull/4056 but that issue is now fixed by
https://github.com/pytest-dev/pytest/pull/2445

Thanks Thomas, I'll kick the failed test once the rest finish. If they're all working this seems fine.

Hmm, the failure seems reproducible but unrelated. It's localized to Pypy with:

```
Fatal Python error: Aborted

Stack (most recent call first, approximate line numbers):
  File "<frozen importlib._bootstrap>", line 220 in _call_with_frames_removed
```

We haven't made any changes that would have affected this, so I'm assuming it's either a GH CI issue or an underlying test depenency isn't playing nicely with Pypy anymore.

I'm fine ignoring for this PR while we track that separately.

Looks like the 18.04 runners aren't getting picked up anymore: https://github.com/psf/requests/issues/6417

> Hmm, the failure seems reproducible but unrelated. It's localized to Pypy with:
> 
> ```
> Fatal Python error: Aborted
> 
> Stack (most recent call first, approximate line numbers):
>   File "<frozen importlib._bootstrap>", line 220 in _call_with_frames_removed
> ```
> 
> We haven't made any changes that would have affected this, so I'm assuming it's either a GH CI issue or an underlying test depenency isn't playing nicely with Pypy anymore.
> 
> I'm fine ignoring for this PR while we track that separately.

@nateprewitt I think failing due to trustme's dep on cryptography https://github.com/psf/requests/issues/6419#issuecomment-1518119021

@nateprewitt yep it was cryptography, here's the fix https://github.com/psf/requests/pull/6421
vague comment in `help.py`

The comment in https://github.com/psf/requests/blob/main/requests/help.py#L60 is difficult to understand. Is it possible to provide a clear explanation?

Do you mean `#Complete Guess`?

This is a comment Kenneth made stating he shipped this without testing it. As in "This is entirely a guess".

This is an ancillary file not intended for use outside of Requests, so it's unlikely we'll make an material changes to what's in there.
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

When trying to post to an API I get the following error: 

` raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
[17/Apr/2023 10:52:46] "POST /Depositos/crear HTTP/1.1" 500 187142`.

The code I'm trying to run is:

`x = session.post(url, data = json.dumps(data))
        message = x.json()
        print(message)

        if x.status_code == 201:
            sweetify.success(request, 'Deposito creado correctamente')
            return redirect('deposito_nuevo')
        else:
            sweetify.error(request, 'Ha ocurrido un error', text=message["error"]["message"]["value"])
        return redirect('deposito_nuevo')`

The libraries that I am using are the following:
sgiref               3.6.0
certifi               2020.6.20
chardet               3.0.4
charset-normalizer    3.1.0
Django                4.1.7
django-simple-history 3.3.0
django-widget-tweaks  1.4.8
gunicorn              20.0.4
idna                  2.10
pip                   23.0.1
psycopg2              2.9.5
psycopg2-binary       2.9.5
pytz                  2020.1
requests              2.28.2
setuptools            67.6.0
six                   1.15.0
sqlparse              0.3.1
sweetify              2.3.1
tzdata                2022.7
urllib3               1.25.9
wheel                 0.38.4



Hi there! Thanks for opening this issue. Unfortunately, it seems this is a request for help instead of a report of a defect in the project. Please use [StackOverflow](https://stackoverflow.com) for general usage questions instead and only report defects here.

Note that the remote end is closing the socket in violation of the protocol. This isn't a bug in requests
no cookies returned when executing on AIX.

Summary.

Connecting to an API that returns cookies is not returning cookies if the script is executed from an AIX environment.

## Expected Result

I expected response.cookies to contain data.

If I execute the identical code, on identical python version, identical package versions on window and linux, it works fine.

## Actual Result

reponse.cookies=<RequestsCookieJar[]>
An empty CookieJar

## Reproduction Steps

```python
import requests

response = requests.request('POST', url=url, verify=False, json=body)
print(f'cookies={response.cookies}')

```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "charset_normalizer": {
    "version": "2.1.1"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.8"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.3"
  },
  "platform": {
    "release": "1",
    "system": "AIX"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.28.2"
  },
  "system_ssl": {
    "version": "1000212f"
  },
  "urllib3": {
    "version": "1.25.3"
  },
  "using_charset_normalizer": false,
  "using_pyopenssl": false
}

```

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).


I did a lot of manual debugging with PDB.

I found that where it is failing is on the check for the session expiration. On AIX it calculates that the session is expired. This appears to be an issue with the conversion of the date/time string to epoch.

Nevermind, time was off on the aix server.
SOCKS5 proxies are not being used when specified - results to using machine IP address

Today I was testing proxies and was able to use them effectively at the start of the day, however after re-running the code a few hours later, the proxies stopped working.

Before anyone asks, I have checked the proxies are still functioning, I know this through my paid proxy provider and checking my proxy IP in a browser using foxyproxy (a browser extension which allows you to login to a proxy). I also am 100% certain that the proxies are in the correct format. (socks5://user:pass@ip:port)

I find this extremely weird, since the same code was used a few hours prior and now it suddenly has stopped working.

## Expected Result

{"ip": **THE PROXY IP**}

## Actual Result

{"ip": **MY HOME IP**}

## Reproduction Steps

```python
import requests

proxy = {'http': 'socks5://user:pass@ip:port', 'https:': 'socks5://user:pass@ip:port'}

r = requests.get("https://api64.ipify.org?format=json", proxies=proxy)

print(r.text)
```

## System Information

    $ python -m requests.help

```json
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "3.0.1"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.4"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.11.1"
  },
  "platform": {
    "release": "21.6.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.28.2"
  },
  "system_ssl": {
    "version": "1010111f"
  },
  "urllib3": {
    "version": "1.26.14"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}
```


We don't have a feature to rewrite our code for socks proxy users after a few hours of use.

This sounds like a provider rate limiting your access via requests since some get complaints of people using the proxy to bypass access restrictions and scrape content. 

To be extra clear, this sounds like an issue between you and your proxy. Whether that's something in your machine's environment or something between you and your proxy, or something your proxy has decided to do to your Requests usage based on connection characteristics, that's not a bug in Requests. If you want help diagnosing your proxy's issues you're better served talking to your provider who you're paying for this service.

By your own admission, requests properly utilizes your proxy until something outside of requests changes. This this isn't a bug in requests 

curl -x socks5://user:pass@ip:port 'https://api64.ipify.org?format=json' works completely fine. Its just python that doesn't work. Do you have any idea on where to look to fix this. It could be something to do with my machine. Thanks

Sorry, about that "'https:':" that where i went wrong :(
request/cookies.py -> RequestCookieJar inheritance update from collections

I have updated the RequestCookieJar class to be compatible with python3.10^ on Linux machines using python3.10^ as the default versions and also compatibility with pymongo.


**The error**
```
module 'collections' has no attribute 'MutableMapping'
```



<details>

<summary>Pymongo full error</summary>

>You can add text within a collapsed section. 

You can add an image or a code block, too.

```python
File "<root-folder>/<app/folder>", line 4, in <module>
    from pymongo import MongoClient
  File "<root-folder>/.local/lib/python3.10/site-packages/pymongo/__init__.py", line 92, in <module>
    from pymongo.mongo_client import MongoClient
  File "<root-folder>/.local/lib/python3.10/site-packages/pymongo/mongo_client.py", line 59, in <module>
    from pymongo import (
  File "<root-folder>/.local/lib/python3.10/site-packages/pymongo/uri_parser.py", line 32, in <module>
    from pymongo.srv_resolver import _HAVE_DNSPYTHON, _SrvResolver
  File "<root-folder>/.local/lib/python3.10/site-packages/pymongo/srv_resolver.py", line 21, in <module>
    from dns import resolver
  File "<root-folder>/.local/lib/python3.10/site-packages/dns/resolver.py", line 39, in <module>
    import dns.query
  File "<root-folder>/.local/lib/python3.10/site-packages/dns/query.py", line 47, in <module>
    import requests
  File "<root-folder>/.local/lib/python3.10/site-packages/requests/__init__.py", line 63, in <module>
    from . import utils
  File "<root-folder>/.local/lib/python3.10/site-packages/requests/utils.py", line 27, in <module>
    from .cookies import RequestsCookieJar, cookiejar_from_dict
  File "<root-folder>/.local/lib/python3.10/site-packages/requests/cookies.py", line 172, in <module>
    class RequestsCookieJar(cookielib.CookieJar, collections.MutableMapping):
AttributeError: module 'collections' has no attribute 'MutableMapping'
```

</details>

The Cookie Jar already inherits from `collections.abc.MutableMapping`. it is imported correctly in the compat module.

I suspect you're using a version of requests that's too old
Title: Add "Setting Up a Local Development Environment" to README

This pull request adds a new section titled "Setting Up a Local Development Environment" to the README.md file. This section provides clear instructions for contributors on how to set up a local development environment for the Requests project. The addition of this section will make it easier for new contributors to get started with the project and ensure a smooth onboarding process.

The new section includes:

    Instructions on installing necessary dependencies
    Cloning the repository
    Creating and activating a virtual environment
    Installing project requirements
    Running tests

By providing this information in the README.md, we aim to lower the barrier to entry for potential contributors and make the project more accessible to developers of all experience levels.

Please review the changes and let me know if you have any suggestions or require further modifications. I'm more than happy to make any necessary adjustments. Thank you for considering this contribution!
Request() not defined

<!-- Summary. -->
I have been using the Request() function for months in this form:

 req = Request(
    url=url_c, 
    headers={'User-Agent': 'Mozilla/5.0'})
    with urlopen(req) as response:
        webpage=response.read()
        soup = BeautifulSoup(webpage)

Until yesterday, my code above returned a beautiful soup object and then all of a sudden yesterday the Request() function just stopped working.

<!-- What you expected. -->

It returned this name error:

NameError: name 'Request' is not defined

I tried re-importing and  reinstalling requests and restarting my kernel several times but to no avail.
I am using Python 3.10.8- and requests version 2.28.1

I see that that there is a requests.get function but I want to know why the function was working fine for months and then all of a sudden it wasn't recognized anymore.




hi @ferrariaria, nothing has changed with Requests. I would suggest double checking your local environment and code again. If Request is not defined, you've failed to import it properly. Unfortunately we aren't able to help with setup debugging on this issue tracker, we recommend posting on [StackOverflow](https://stackoverflow.com/) with further questions. Thanks!
🛠 fix: Adapter overwrite passed-in retry

According to the API reference of `max_retries` of `requests.adapters.HTTPAdapter`

> The maximum number of retries each connection should attempt. Note, this applies only to failed DNS lookups, socket connections and connection timeouts, never to requests where data has made it to the server. By default, Requests does not retry failed connections. If you need granular control over the conditions under which we retry a request, **import urllib3’s Retry class and pass that instead.**

A widely used example can be found in this [StackOverflow answer](https://stackoverflow.com/a/35504626/10325430) and is also under review in #6258.

However, the current source code does not really accept the passed-in `Retry` instance. Instead, it will silently discard and replace it with the default `Retry` instance.

This 2-line fix intends to fix the bug and restore its behavior to expect.

You haven't provided evidence that this isn't working. The `from_int` classmethod returns the Retry instance if it's already a Retry 

My mistake. Turns out I used the wrong scheme (`http://` should be `https://`) when mounting in my previous test.

Closing this PR, but do look into #6258 and get it merged. Took me a while to get this snippet that should've been in official docs.
requests prepare_request Valid on MacOS but not on Linux

I referred to https://github.com/psf/requests/issues/6385 , using PrepareRequest workflow to implement the method of retaining original characters in urls

The following code, which I run on my local MacOS, actually sends a URL of ' http://example.com/?unix:abc | http://127.0.0.1/ ', but when I ran it on Linux, the actual URL changed to' http://example.com/?unix:abc%7Chttp://127.0.0.1/ ', I checked that the versions of the requests library are the same, they are all 2.28.2. Why

```
import requests
s = requests.Session()
prepped = s.prepare_request(requests.Request('POST', 'http://example.com/', data={"a":"1"}, headers={'User-Agent':'test'}))
prepped.url = 'http://example.com/?unix:abc|http://127.0.0.1/'
res = s.send(prepped,proxies={'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'})
```
<img width="502" alt="image" src="https://user-images.githubusercontent.com/48439183/227627197-01ef12d5-2a25-411c-8a60-f3aa714c7369.png">


I have found the reason. Requests rely on urllib3 to process urls. urllib3=1.22 can meet my requirements, but the new version won't work. Therefore, when using the new version of urllib3, it is still necessary for me to https://github.com/psf/requests/issues/6385 Suggestions

If it's necessary for you to use a pipe like that unencoded something you're interacting with isn't a well implemented server that respects how it should behave. Requests can only give you so much ability to do the wrong thing. At this point requests has no way to prevent urllib3 from also doing the right thing (nor do we really want to prevent it from doing the right thing).
docs: Remove non needed spacing

I'm sorry for my OCD 😅
There is some extra spacing. This doesn't match the spacing of the badge `downloads/month`

![image](https://user-images.githubusercontent.com/72306953/226908616-73cdf003-4d45-4199-a8c4-0731b9e0a551.png)


We don't accept cosmetic changes. Thanks for sending this
Can choose whether to perform automatic url encoding and decoding

When I request with get, the content in the url will be automatically encoded or decoded or some other processing will be performed
Here are two examples:
[Example 1]
My real need is to send ' http://examole.com/1.jsp ;? Id=1 ', but in this example, the'; 'in the url Will be automatically ignored
```
import requests
url = ' http://examole.com/1.jsp ;? id=1'
res = requests.get(url, proxies={'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'})
```
When I try to manually encode the url first, the actual request becomes' http://examole.com/1.jsp%3b%3fid%3d1 '
```
url = ' http://examole.com/%31%2e%6a%73%70%3b%3f%69%64%3d%31 '
res = requests.get(url, proxies={'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'})
```
[Example 2]
My real need is to send ' http://examole.com/1.jsp?id=1 |Tid=2 ', in this example,' | 'will be encoded as'% 7C'
```
import requests
url = ' http://examole.com/1.jsp?id=1 |tid=2'
res = requests.get(url, proxies={'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'})
```
When I try to manually encode the url first, the actual request becomes' http://examole.com/1.jsp%3fid%3d1%7ctid%3d2 '
```
url = ' http://examole.com/%31%2e%6a%73%70%3f%69%64%3d%31%7c%74%69%64%3d%32 '
res = requests.get(url, proxies={'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'})
```

I cannot modify the source code of requests because it will affect the functionality of other businesses. Therefore, I hope you can provide an optional parameter to determine whether to send the original URL request.

For example:
```
res = requests.get(url, no_encode=False,proxies={'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'})
```
When no_ The default value of encode is True, which has the same effect as the current version. If no_ Encode=False, then the original url is sent without any processing.

Hi @heikanet, this is already possible with the PrepareRequest workflow described in our docs.

https://docs.python-requests.org/en/latest/user/advanced/#prepared-requests
Clarify docs for multipart file uploads

This makes some documentation changes that clarify the `files` argument of `requests.post()` et. al.

## Be more precise when we say "multiple files"

The `files` argument can either be a dict:

```python
files = {
    "field_1": file_1,
    "field_2": file_2,
}
```

Or a list of tuples:

```python
files = [
    ("field_1": file_1),
    ("field_2": file_2),
]
```

A few places implied that to "upload multiple files in one request," you had to use the list-of-tuples syntax. But the dict syntax supports multiple files just fine. The added power in the list-of-tuples syntax seems to be that you can upload multiple files *to the same form field.* So, we now say that.

## Update the reference docs

The API reference documentation did not completely describe what values were acceptable for `files`, and in some cases it was misleading.

* It didn't mention the list-of-tuples syntax at all.
* It said you could pass a "dictionary of `'name': file-like-objects`". The pluralization there makes it look like you can do something like `{"name": [file_1, file_2]}`, but that's not correct.
* It didn't describe what you were allowed to provide as a "`fileobj`". (It can be a file-like object, or `str` contents, or `bytes` contents.)
* It said `name` to refer to the value that Requests uses as the form field name. This could be misconstrued as the file name. [RFC 7578](https://www.rfc-editor.org/rfc/rfc7578) and other examples within Requests call it the "field name" or "form field name."

My sources for these changes:

* The existing [POST a Multipart-Encoded File](https://github.com/psf/requests/blob/7f694b79e114c06fac5ec06019cada5a61e5570f/docs/user/quickstart.rst?plain=1#L300) section.
* The existing [POST Multiple Multipart-Encoded Files](https://github.com/psf/requests/blob/7f694b79e114c06fac5ec06019cada5a61e5570f/docs/user/advanced.rst?plain=1#L391) section.
* [Request's type stubs](https://github.com/python/typeshed/blob/8080e491d2fa92b1b1390c87fac23a1a38dcd919/stubs/requests/requests/sessions.pyi#L91).

It's difficult to describe this API concisely because it accepts so many different input shapes, and these additions do make the rendered docs feel a bit crowded.

The primary benefit of using list of tuples is that order is preserved which is important for some servers that expect fields in a very specific ordering which is way more than it should be

@sigmavirus24 Thanks. To be clear, do you think some of this PR needs to change to reflect that, or were you just commenting to lend context?

Bump. Are any changes needed for this?
Not possible to specify positional params in URLs

Currently it's not possible to supply values for positional only parameters in request URLs.
E.g Http requests like this are not supported:
`URL?param1=value,some_other_param`

Currently it is possible to specify a key-value pair for `param1` but not only a value for `some_other_param`.
It's possible to concatenate the URL by oneself, but I doubt this is the recommended way to do so.

## Expected Result
Example:
`req = requests.get(URL, {"param1": "value1"}, positional_params = ["some_other_param"])`

## Actual Result
Only possible to concatenate the URL by oneself:
`req = requests.get(f"URL?param1={value},some_other_param")`, which is OK for simple requests but not OK
for complex requests.

The same goes for POST requests.

In the future, please search **closed and** open issues before creating new ones that are duplicates.
fix issue #6377

fix #6377 
The reason why the file is not overwritten is that the test file in the TMP directory is not cleared after the test is run for the first time, and the directory and filename of the temporary file are the same after each test run.

This code skips overwriting when it finds that the file already exists:

`if not os.path.exists(extracted_path):` in utils.extract_zipped_paths()

**This means that calling this function twice in a row will not be able to detect changes in compressed files？**

So i thought that judgment might be redundant, so I removed it.

This will dramatically kill performance for people using certifi and requests from zip files. We won't be accepting it

> This will dramatically kill performance for people using certifi and requests from zip files. We won't be accepting it

Sorry, I'm a noob.  @sigmavirus24 
Is it acceptable to use MD5 to compare existing files in a temporary directory with the compressed file to detect if the contents of the file have changed?

```
import hashlib

def extract_zipped_paths():
    ...
    if os.path.exists(extracted_path):
        with open(extracted_path, "rb") as file_handler:
            file_content = file_handler.read()
            file_hash = hashlib.md5(file_content).hexdigest()
        zip_file_hash = hashlib.md5(zip_file.read(member)).hexdigest()
        
        if file_hash == zip_file_hash:
            return extracted_path
        
    # use read + write to avoid the creating nested folders, we only want the file, avoids mkdir racing condition
    with atomic_open(extracted_path) as file_handler:
        file_handler.write(zip_file.read(member))
```
How to setup local dev environment and run the tests?

As I have not seen any details about it (beyond the cloning of the repo) in the README I put together a short blog posts on [Development environment for the Python requests package](https://dev.to/szabgab/development-environment-for-the-python-requests-package-eae) If you are interested, I'd be glad to send a PR for the README file to include some similar information.

To set up a local development environment for the Python Requests library and run tests, you can follow these steps:
Fork the Requests repository (https://github.com/psf/requests) on GitHub.
git clone https://github.com/<your_username>/requests.git
cd requests
python -m venv venv
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
pip install -e .
pip install -r requirements-dev.txt
pytest
test_zipped_paths_extracted fails if test file has been modified since last run

If you run `python -m pytest tests/test_utils.py -ktest_zipped_paths_extracted` this test will pass normally. If you run it again, it will pass again.

If, however, you make any modifications to the file, the test will now fail and keep failing:

```       assert filecmp.cmp(extracted_path, __file__)
E       AssertionError: assert False
E        +  where False = <function cmp at 0x7f4ea6d4dab0>('/tmp/test_utils.py', '/home/david/project-reducer/scratch/requests/tests/test_utils.py')
E        +    where <function cmp at 0x7f4ea6d4dab0> = filecmp.cmp
```
The reason for this is that the last time the test ran, the contents of `__file__` were written to `/tmp/test_utils.py` and when `extract_zipped_paths` is next called, it doesn't overwrite the existing file, so the filecmp fails because it's now comparing against the old version of the file.

## Expected Result

The test should run successfully when modifications to the file are made.

## Actual Result

Modifications to the test file that are unrelated to the test in question cause it to fail.

## Reproduction Steps

```bash
python -m pytest tests/test_utils.py -ktest_zipped_paths_extracted
echo -n '# modification' >> tests/test_utils.py
python -m pytest tests/test_utils.py -ktest_zipped_paths_extracted
```
## System Information

    $ python -m requests.help

```json
{
  "chardet": {
    "version": "5.1.0"
  },
  "charset_normalizer": {
    "version": "3.0.1"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.4"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.10.8"
  },
  "platform": {
    "release": "5.15.90.1-microsoft-standard-WSL2",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.28.2"
  },
  "system_ssl": {
    "version": "1010106f"
  },
  "urllib3": {
    "version": "1.26.14"
  },
  "using_charset_normalizer": false,
  "using_pyopenssl": false
}
```
ddg-api.herokuapp.com return 500

<!-- Summary. -->

## Expected Result
200
<!-- What you expected. -->

## Actual Result
500
<!-- What happened instead. -->

## Reproduction Steps

```python
import requests

```

## System Information

    $ python -m requests.help

```json
{
  "paste": "here"
}
```

<!-- This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c). -->
InvalidHeader exception when using subclass of str or bytes

An InvalidHeader is raised while preparing a request using a subclass of `str` instead of `str` or `bytes` in headers.

## Origin
This is due to type checking in check_header_validity in utils.py. This type check uses `type` instead of `isinstance`.

## Context
The need of using subclass of str instead of str comes from the need to have 2 "Authorization" header and not just one with 2 tokens separeated by a comma.

PS: I didn't build the API i am requesting, don't blame me.

A correction could be:
```python
def check_header_validity(header):
    """Verifies that header parts don't contain leading whitespace
    reserved characters, or return characters.

    :param header: tuple, in the format (name, value).
    """
    
    name, value = header
    types = {}

    for part in header:
        for valid_type in HEADER_VALIDATORS:
            if isinstance(part, valid_type):
                types[part] = valid_type
                break
        else:
            raise InvalidHeader(
                f"Header part ({part!r}) from {{{name!r}: {value!r}}} must be "
                f"of type str, bytes or subclasses of them, not {type(part)}"
            )

    _validate_header_part(name, "name", HEADER_VALIDATORS[types[name]][0])
    _validate_header_part(value, "value", HEADER_VALIDATORS[types[value]][1])
```

Hi @hpierre001, please check open and closed issues before creating new ones. Thanks!
Problem with data parameter in request.post()

<!-- Summary. -->

## Expected Result
When assign `data` as a `dict` type, it should work.

<!-- What you expected. -->

## Actual Result
When I input a dict to `data` parameter, it doesn't work.
<!-- What happened instead. -->

## Reproduction Steps

```python
import requests
import json

url = 'https://simple-books-api.glitch.me/api-clients'
payload = {
   "clientName": "Gnafiy",
   "clientEmail": "examplefdasf@reed.edu"
}
r = requests.post(url, data=payload)
print(r.request.body) # this will print something like bookId=2&customerName=John+Smith
print(r.text) # this suppose to print "error": "API client already registered. Try a different email." but it's printing "error":"Invalid or missing client name."
```

## System Information

    $ python -m requests.help

```json
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "2.1.1"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.4"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.10.7"
  },
  "platform": {
    "release": "21.6.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.28.1"
  },
  "system_ssl": {
    "version": "1010111f"
  },
  "urllib3": {
    "version": "1.26.12"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}
```

<!-- This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c). -->

You should pass the `payload` using `json` parameter instead of `data`.

```
r = requests.post(url, json=payload)
```

@zhu-yifang, I'm going to have to ask you please read the docs before posting new issues. This is all answered for you. Pinging 1000+ people isn't a productive use of time.

If you have usage questions please check Stack Overflow and the python-requests tag.

Thank you @Mariatta for the quick response.
Parse cookies set by Django app

I'm using requests to automate a custom Django app.
The Django app sets cookies that are not parsed by requests.

This addresses two issues that keep requests from parsing the cookies:

1. A Set-Cookie header with multiple cookies will fail to parse
2. A Set-Cookie with a Max-Age attribute that is a floating point number will fail to parse

Django does both of these things.

This PR handles multiple cookies by replacing a single Set-Cookie header with multiple cookies with multiple Set-Cookie headers with one cookie each.

This PR rounds down Max-Age to an int.

4 new tests are added.

I believe this would be an issue with any HTTP client using the standard library for cookie parsing. I'm not sure that makes it appropriate to fix here

Hi @jazzdev, looking over the PR, it seems Django may be doing the wrong thing in this case. It's not clear from what's been provided whether this is due to user input or a defect in Django. Requests uses the standard library to parse cookies and I'm not sure we want to start building out our own parsing.

This is what I see in the specifications regarding what you're seeing (emphasis mine):

<blockquote>
   If the attribute-name case-insensitively matches the string "Max-
   Age", the user agent MUST process the cookie-av as follows.
   
   If the first character of the attribute-value is not a DIGIT or a "-"
   character, ignore the cookie-av.

   **If the remainder of attribute-value contains a non-DIGIT character,
   ignore the cookie-av.**

   Let delta-seconds be the attribute-value converted to an integer.
</blockquote>

\- [RFC 6265 5.2.2](https://www.rfc-editor.org/rfc/rfc6265.txt)

A value containing anything other than a DIGIT or a "-" character means the entire value is ignored.

For bundling multiple cookies into a single `Set-Cookie` header, it's not strictly a spec violation but definitely goes against what's advised.

> Origin servers SHOULD NOT fold multiple Set-Cookie header fields into
   a single header field.
   
The latest HTTP/1.1 RFC (9110) takes it a step farther stating they mechanically cannot be combined due to parsing implementation issues like you're seeing. Regarding collapsing cookies based on matching keys:

> Since it cannot be combined into a single field value, recipients ought to handle "Set-Cookie" as a special case while processing fields.
[RFC 9110 5.3](https://www.rfc-editor.org/rfc/rfc9110#section-5.3-4.1)

--

For those reasons, I think we're not inclined to add this functionality. It's going to move us into an awkward position where we cannot do the correct thing in all cases. Trying to support violations of the RFCs has bitten us previously so ideally this should be fixed either in the app or Django depending on the origin of the issue.
Please consider making a public interface for `requests.utils._parse_content_type_header`

Hi,

I have some code using `requests` where I want to check that the response the response has the expected content-type, but I don’t care about the encoding. Parsing the Content-Type header is not very complicated, but `requests` already does it in its `requests.utils._parse_content_type_header` function, that is used to find the encoding in `requests.utils.get_encoding_from_headers`. I’d rather not reinvent the wheel.

However, as far as I can tell, that `requests.utils._parse_content_type_header` function is undocumented and, given its name starts with an underscore, it looks like a private function that might be removed in a future release.

It seems to me it that it is a common need to parse a Content-Type header and, given `requests` already had a function to do so, would you consider making a public interface for this?

Requests is in feature freeze at the moment and not expanding or changing the public API. As such, we will not guarantee the stability of availability of that function, nor will we be making it public
Response class does not pickle _next attribute

When using requests without following redirects the Response objects do not retain the _next PreparedRequest when pickled.

## Actual Result

```
>>> res = pickle.loads(pickle.dumps(requests.Response()))
>>> res.next
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pete/Library/Python/3.9/lib/python/site-packages/requests/models.py", line 788, in next
    return self._next
AttributeError: 'Response' object has no attribute '_next'
```


## Fix?

```
>>> requests.models.Response.__attrs__ += ['_next']
>>> res = pickle.loads(pickle.dumps(requests.Response()))
>>> res.next
>>>
```


What you have here is a bug without a use case to motivate it. Why are you pickling responses and trying to follow redirects in another place after unpickling? The next attribute would be unwise to try to pickle and unpickle.

In short, we almost certainly don't want to support this. But you haven't told us why you think we should 

I have a script that makes requests without following redirects and caches the objects for offline replay. It's not transferring responses to another place. It does consume the Response.next.url if it is present.

If you don't want to make it pickleable, you could just init the _next attribute in __setstate__ like raw.

Next is deprecated because it should never have been implemented. You want the value of the Location header

Did you just make that up? Anyway, I just thought you should know.

The issue tracker has plenty of bugs including one with a plan to get rid of the attribute. No I didn't just make it up.