Raibek/requests-github-issues huggingface dataset:
Upgrade idna to 3.7 for CVE-2024-3651

<!-- Summary. -->
Now that idna released [3.7](https://github.com/kjd/idna/releases/tag/v3.7), can you consider bump the requires to `idna>=3.7,<4`?

## Expected Result

Get rid of [CVE-2024-3651](https://github.com/advisories/GHSA-jjg7-2v4v-x38h)

## Actual Result

SAST analysis shows [CVE-2024-3651](https://github.com/advisories/GHSA-jjg7-2v4v-x38h)

## Reproduction Steps

n/a

## System Information

n/a 

<!-- 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). -->


Use a better SAST. 

The [requirement](https://github.com/psf/requests/blob/main/setup.cfg#L9) does not forbid you using 3.7. If you aren't also managing your transitive dependency versions a reinstall of requests should pull this unless you have something else blocking you from using that version.
Fix raise for status #6683

Fix `raise_for_status()` behaviour to comply with documentation as per [issue #6683](https://github.com/psf/requests/issues/6683). In particular, makes it return the response to ease chaining in trivial cases.

> I'm not convinced the documentation was ever right it that we should change the code to comport

I see, if that's the case feel free to close the pull request, fixing the documentation would do as well, although returning the response seemed useful.

Yeah I'd want Nate's input too when he has time. I'm more inclined to fix the docs 

This looks wrong. The documentation being linked in the original issue is not our documentation, it's Kenneth's 3.x fork. This was a requested feature several years ago to allow for more functional programming with something like `response.raise_for_status().content` which was rejected. If Kenneth added it to his 3.x branch, that's not something we'll be supporting.

I'm not able to find this line in any of our [public docs](https://requests.readthedocs.io/en/latest/user/quickstart/#response-status-codes), but if you are able to, please provide a link. I'm going to close this PR out as won't fix since this isn't expected behavior, we can discuss any instances of this in the official docs in the tracking issue. Thanks!
Fixed #6683

Since the documentation says that it should return a response object in case of no difficulties and the code didn't seem to, I added a statement to return the response object at the end.
[This is the issue](https://github.com/psf/requests/issues/6683)


In hindsight perhaps a test wouldn't hurt

My bad, you are absolutely right. I'll get to it.

All good man :thumbsup: I don't have merge rights so can't really do much here anyway :smile: I raised it just in case :shrug: 

Thanks for the PR @ManiFaridi. This isn't something we'll likely be adding though, please refer to the original issue for more information.
raise_for_status documentation is out of sync

Not a bug per se, more like a discrepancy between documentation and actual behaviour.

## Expected Result

The [documentation](https://3.python-requests.org/user/quickstart/#response-status-codes) says `response.raise_for_status()` should return the response for chaining in trivial use cases.  

![Screenshot from 2024-04-14 11-19-57](https://github.com/psf/requests/assets/7195133/7c1ea32f-a356-4ab2-b549-08544ea11792)


## Actual Result

The code in the latest version of package doesn't actually allow it, see [raise_for_status in models.py](https://github.com/psf/requests/blob/v2.31.0/requests/models.py#L994)


## Reproduction Steps

```
...
    response.raise_for_status().json()
AttributeError: 'NoneType' object has no attribute 'json'
```

Hi @dennyb87, thanks for raising this. I responded in a comment here in [your PR](https://github.com/psf/requests/pull/6685#issuecomment-2057416891). If you can provide examples from the official docs hosted on readthedocs, we'd be happy to fix this, but from what I can see currently, this never existed in the Requests documentation. What you provided above is an unmaintained fork we do not have control over.

Nice catch @nateprewitt . I didn't have time to click through but the screenshot seemed convincing

Ouch :facepalm: that's embarrassing :sweat_smile: my bad! apologies for the annoyance :wave: 

No worries, thanks for checking in!
what if someone sets both data and files when making a request?

from the [docs](https://requests.readthedocs.io/en/latest/api/):

**data** – (optional) Dictionary, list of tuples, bytes, or file-like object to send in the body of the [Request](https://requests.readthedocs.io/en/latest/api/#requests.Request).

**files** – (optional) Dictionary of 'name': file-like-objects (or {'name': file-tuple}) for multipart encoding upload. file-tuple can be a 2-tuple ('filename', fileobj), 3-tuple ('filename', fileobj, 'content_type') or a 4-tuple ('filename', fileobj, 'content_type', custom_headers), where 'content_type' is a string defining the content type of the given file and custom_headers a dict-like object containing additional headers to add for the file.

what happens if someone sets both? i ask because AFAIU, `files` is sent in the request body

As described in the template, we won't be able to answer questions on this issue tracker. Please use [Stack Overflow](https://stackoverflow.com/)
Add rfc9110 HTTP status code names

RFC 9110 _HTTP Semantics_ obsoletes some earlier RFCs which defined HTTP 1.1. It adds some status codes that were previously only used for WebDAV to HTTP _proper_ after making the names somewhat more generic.

See https://www.rfc-editor.org/rfc/rfc9110.html#name-changes-from-rfc-7231

This commit adds the http status code names from that RFC.

RFC 9110 has been accepted as Internet Standard in June 2022.

In https://github.com/psf/requests/blob/main/docs/user/advanced.rst#compliance  it states:

> Requests is intended to be compliant with all relevant specifications and RFCs where that compliance will not cause difficulties for users. 

So it seems only logical that the status code descriptions found in that RFC are also available in Requests
pytest.warns(None) is no longer supported

Not sure what was this code supposed to mean (making sure that there are no warnings? I don't think it ever did that?), but on pytest 8 it no longer works: "TypeError: exceptions must be derived from Warning, not <class 'NoneType'>"

https://docs.pytest.org/en/latest/how-to/capture-warnings.html#additional-use-cases-of-warnings-in-tests

From the pytest's changelog:

> #8645: pytest.warns(None) is now deprecated because many people used it to mean “this code does not emit warnings”, but it actually had the effect of checking that the code emits at least one warning of any type - like pytest.warns() or pytest.warns(Warning).

And this is the code we are talking about:

https://github.com/psf/requests/blob/2a438c27b5a5828c8ea0dc958112eecffca70b12/tests/test_requests.py#L1006-L1008

In our testing environment with pytest 8.1.1 and urllib3 < 2.0 removing the None from `pytest.warns` fixes the problem.

I'm not sure why the last comment by @kloczek has been removed but PR with the simple fix is ready.
Adds json.JSONDecodeError from standard library to requests.JSONDecodeError

Below is a suggestion for slightly enhancing the `JSONDecodeError` behavior.

### Background
The [comments](https://github.com/psf/requests/blob/main/src/requests/models.py#L972) for the `json()` method of `Response` say that `requests.JSONDecodeError` should alias the JSONDecodeError from the standard `json` library (`json.JSONDecodeError`) and `simplejson.JSONDecodeError`. 

### Problem
When `simplejson` is installed, `requests.JSONDecodeError` is not an instance of `json.JSONDecodeError`

### How to reproduce
1. Install `simplejson` in a virtual environment
```
pip install simplejson
```
2. Without the proposed change, [this test](https://github.com/psf/requests/compare/main...jon-behnken:requests:main#diff-05180dda5cdc530f95d400932961d6152bd515a6447af23d22c7f335b390b9d8R2810) should fail:
```
pytest tests/test_requests.py -k test_json_decode_compatibility 
```

### Why
Implementations like this should behave as expected:
```
try:
    response = requests.get("https://www.example.com/data").json()
except json.JSONDecodeError:
    # do something
```
but this exception does not get caught. Currently you must use `requests.exceptions.JSONDecodeError` which is a bit unintuitive. 

I think the docs aren't sufficiently clear but with this PR you're now doubly inheriting from the stdlib JSONDecodeError if there's no simplejson which seems rather silly. The reason we inherit from whichever library is used is because people had been previously catching that and others reasonably expected to be able to catch an exception from requests. It's not meant such that you can always catch the stdlib exception class

I agree with sigmavirus24, the example behavior isn't how this exception was intended to work. It was made to provide a shim allowing code to function regardless of the dependencies available. I'd be happy to review a doc PR to clarify intent of the exception, but don't think this PR is the right path for addressing any confusion.

It's not even how it's documented I think. I think this is purely talking about an inaccurate code comment
Fix utils functions with invalid ip/cidr inputs

- add test cases reported in #5131
- fix utils functions `address_in_network`, `is_ipv4_address` and `is_valid_cidr`
- replace socket with `ipaddress` module
- prepare ipv6 support

Fixes #5131

@kennethreitz, @Lukasa, @sigmavirus24, @nateprewitt, @slingamn,

 This is my first contribution to this project, and I don't know if is necessary request to someone to review the PR

@Pjrich1313, 

> Fast node isn't work

How can i test this case?
Feature update


@TheDukeroyalty, we're going to have to ask you please stop opening PRs against this repo. Please refer to my previous comment in #6672 or the [official GitHub PR documentation](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request). Further PRs with the same content may result in restriction of permissions to post in the repository. Thanks for your cooperation.
added a user input prompt.

Intro To Python Assignment
Objective: To learn how to take user input in Python



Write a program that asks the user for their name, age, and location and then prints out a personalized message.




Instructions:
Create a new Python file and name it "user_input.py"
Use the input() function to ask the user for their name and store it in a variable called "name".
Use the input() function to ask the user for their age and store it in a variable called "age".
Use the input() function to ask the user for their location and store it in a variable called "location".
Print out a personalized message using the user's name, age, and location. For example: "Hello [name], you are [age] years old and live in [location]."
Save and run the program to see the output.

Hi @TheDukeroyalty,

You may have accidently opened a PR against the wrong repository. In the future you'll want to do test [PRs against your own repository](https://github.com/TheDukeroyalty/advanced-git_requests/compare/main...TheDukeroyalty:advanced-git_requests:main) by ensuring you have the right Base repository selected. I'll close this out for now.

Hi,

Thank you for bringing this to my attention. I acknowledge that I made a
mistake in opening the PR against the wrong repository. I am currently a
student and was in the process of learning and experimenting with GitHub
for a class assignment. I apologize for any inconvenience this may have
caused. I will ensure to double-check and select the correct Base
repository for any future PRs.

Best regards,


On Mon, Mar 25, 2024 at 10:32 PM Nate Prewitt ***@***.***>
wrote:

> Hi @TheDukeroyalty <https://github.com/TheDukeroyalty>,
>
> You may have accidently opened a PR against the wrong repository. In the
> future you'll want to do test PRs against your own repository
> <https://github.com/TheDukeroyalty/advanced-git_requests/compare/main...TheDukeroyalty:advanced-git_requests:main>
> by ensuring you have the right Base repository selected. I'll close this
> out for now.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/psf/requests/pull/6672#issuecomment-2018759781>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BGDMMFWZXKOXZSB76FRCHE3Y2B3WHAVCNFSM6AAAAABFHTF6IWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJYG42TSNZYGE>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
Consider making certifi an optional dependency

1. In some cases users may need to access some site in a company private network, with SSL certificate signed by custom root certificate (not public). Accessing this site using browser is working fine if user added this root certificate to system cert store. But requests will complain that certificate cannot be verified, and user have to pass this root certificate to `session.verify = '/path/to/cert.pem"` or by passing the same path to `REQUESTS_CA_BUNDLE` env variable. IMHO, this is redundant step which introduces more headache than solves anything.
2. `certifi` has MPL 2.0 license which _may be_ considered as copyleft, and prohibited to use by legals. Not all of users know that MPL 2.0 license is file-based, and license actually cannot "spread" to packages which depend on it.

Is is possible to introduce `pip install requests[certifi]` for installing certifi explicitly, and remove if from default installation?

No
Is feature freeze permanent?

Hi.

For several years I see feature freeze on this project (although I haven't see any announce about it). Are there any plans start to accept new features? Can contributors help with anything?

Lack of new features leads to introducing new HTTP clients like [niquests](https://github.com/jawah/niquests) which do support HTTP/2, QUICK, DNS over HTTPS and so on.

Yes it is. There's an issue describing the feature freeze policy. 

Duplicate #969
Is feature freeze permanent?

Hi.

For several years I see feature freeze on this project (although I haven't see any announce about it). Are there any plans start to accept new features? Can contributors help with anything?

Lack of new features leads to introducing new HTTP clients like [niquests](https://github.com/jawah/niquests) which do support HTTP/2, QUICK, DNS over HTTPS and so on.

As described in the template, Requests is not accepting feature requests
How to download multiple files in local system using POST API request in python rather than in ascii or binary form data ?

I struck in one scenario in which i need to download multiple files in local repository using POST API request in python 3.9.12.

I tried below code but not able to resolve the issue.

```
def download(url: str, dest_folder: str):
    if not os.path.exists(dest_folder):
        os.makedirs(dest_folder)

    filename = url.split('/')[-1].replace(" ", "_")
    file_path = os.path.join(dest_folder, filename)

    payload = {'testcaseId': '305432601'}

    r = requests.post(url, data=json.dumps(payload), stream=False)
    if r.ok:
        print("saving to", os.path.abspath(file_path))
        with open(file_path, 'wb') as f:
            for chunk in r.iter_content(chunk_size=1024 * 8):
                if chunk:
                    f.write(chunk)
                    f.flush()
                    os.fsync(f.fileno())
    else:  # HTTP status code 4XX/5XX
        print("Download failed: status code {}\n{}".format(r.status_code, r.text))


download("https://api.demo.com/siteapi/resultfiles/", dest_folder="//PycharmProjects//Testing_Local//Logs")

```
When I used above code it gives me below error:

```
Download failed: status code 500
{"timestamp":"2024-03-14T11:45:42.109+00:00","status":500,"error":"Internal Server Error","path":"/siteapi/resultfiles/"}
```

**In postman we have that option to SEND and DOWNLOAD files and through that i am able to download multiple files in zip folder in my local system.**

![Screenshot 2024-03-05 at 11 51 16 AM](https://github.com/psf/requests/assets/46193115/0df05a52-d911-4295-a1db-92011c303a90)

My questions are :

1. How to download multiple files in local system or directory using python through POST API request rather than binary stream ?
2. How to achieve task through python code which postman UI is providing through SEND and DOWNLOAD option ?

Below scenario is expected :

1. Fire POST API request
2. DOWNLOAD Files through response of POST API
3. STORE files in local directory.


As described in the template, we won't be able to answer questions on this issue tracker. Please use [Stack Overflow](https://stackoverflow.com/)
Add local TLS server

This also adds certificates for testing purposes and files to make it easy to generate/regenerate them.

This also replaces an existing test of how we utilize our pool manager such that we don't connect to badssl.com

Finally, this adds additional context parameters for our pool manager to account for mTLS certificates used by clients to authenticate to a server.

Ack didn't mean to add that roadmap file. Was a brain dump for years back


> Edit: I guess we've got test failures coming from connection resets.

Yeah I think having a handshake failure causes the socket to be in an unhappy place but I don't feel like making this a perfect server.
chore: change string concatenation way (auth.py)

Referring to [Pep8's recommendation](https://peps.python.org/pep-0008/#programming-recommendations), changed the way strings are concatenated (from `+=` to `''.join`)

We don't accept stylistic changes unless they are part of meaningful work. Furthermore, the recommendation against using string addition is only relevant in large enough numbers of concatenation and is likely irrelevant here. 

Anyway, Thanks for the feedback!
Post requests with unicode chars in string as data sends incomplete/trimmed data (in >=2.30 with urllib3 2.0)

In the *requests*>=2.30.0 (with urllib3 2+), when you send a post request with `data=<a string containing unicode chars>`, the server receives incomplete/trimmed data. This is due to the fact `content-length` set by *requests* will not match the actually sent data.  It is set to len(data), yet it sends data.encoded() - which is longer.

If *requests* uses urllib3 1.x versions this throws an exception, for example:

UnicodeEncodeError: 'latin-1' codec can't encode character '\u0159' in position 10: Body ('ř') is not valid Latin-1. Use body.encode('utf-8') if you want to send it encoded in UTF-8.

## Expected Result

Either:
a) send complete data (where content-length header == len(data.encode()), not len(data) )
b) raise an exception as urlllib3 1.x versions did, suggesting the str should be utf-8 encoded
c) raise an exception telling the user he is not supposed to pass strings to the `data` argument

## Actual Result

No error is reported on the client side, nor is the data sent correctly. Server reads incomplete data.

## Reproduction Steps

```python
import requests
d="Lidová tvořivost na sebe nenechala dlouho čekat."
requests.post('http://localhost:8083/echo', data=d)
```

Server receives `Lidová tvořivost na sebe nenechala dlouho ček` in the requests body,  which is incomplete

## System Information

    $ python -m requests.help

```json
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "2.0.12"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.11.8"
  },
  "platform": {
    "release": "22.6.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.31.0"
  },
  "system_ssl": {
    "version": "300000d0"
  },
  "urllib3": {
    "version": "2.2.1"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}
```

Hi @viiand, this is a duplicate of #6586 which is already fixed in #6589. Please check opened and closed issues before opening new ones. Thanks!
Post Request Status and header error.

I am currently involved in a project where it is necessary to send POST requests to a remote server. I have noticed unexpected behavior when trying to emulate a POST request that I receive from Mozilla Firefox.

Specifically, when I perform the POST request through Mozilla Firefox, I receive a response with HTTP/0.9 without headers and a reported status of 200. However, when I try to emulate the same POST request in Python 3 using the requests library, I do not receive any status code, and I encounter an error "raise ConnectionError(err, request=request) requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine('<html><body>\n'))".

After a more in-depth analysis, I discovered that the server is responding with HTTP/0.9, which may be the cause of the problem. However, I am unable to obtain a valid status code using requests.

To temporarily resolve the issue, I modified the behavior of the _read_status(self) function in the requests library to convert the first line into a valid status code. I also simulated the presence of the line "line = b'\r\n'" in the header to avoid issues when reading the headers.

How can I correctly interpret the response from the server? My request header is as follows:

Here is the code:
`
import requests

uid = "3491282510"
url = f'https://10.97.80.44/goform/formPostData?LE=ethPortCfg&UID={uid}'
print(url)

headers = {
    "User-Agent": "Mozilla/5.0",
    "Accept": "application/xhtml+xml",
    "Accept-Language": "en-US,en;q=0.5",
    "Accept-Encoding": "gzip, deflate, bz"
}

data = {
    'fd0': '0/2',
    'fd1': 'Port 2',
    'fd2': '0/2',
    'fd3': '1000X',
    'fd4': 'Disabled',
    'fd5': 'On',
    'fd6': '1G',
    'fd7': 'Full',
    'fd8': 'Off',
    'fd9': 'Off',
    'fd10': 'On',
    'fd11': 'Do nothing',
    'fd12': 'N/A',
    'fd13': '5',
    'choice': 'Apply'
}

response = requests.post(url, headers=headers, data=data, verify=False)
print(response.status_code)
# Output the response content
print(response.text)
`
How i can solve this issue?
ty

As described in the template, we won't be able to answer questions on this issue tracker. Please use [Stack Overflow](https://stackoverflow.com/)
The content for this response was already consumed 

 I am using response.iter_content(chunk_size=None)) to read stream data also kept stream = True, here i am trying to read set of jsons in a loop, but if something breaks due to network issue (which i observed it does removes some characters) and its not complete json i kept except condition to read from response.text for which  I am getting an error -->The content for this response was already consumed 

## Expected Result

it should read set of json as a stream data in a loop using response.iter_content(chunk_size=None)) and if it breaks or missing something than it should read complete data from response.text in except condition

## Actual Result

i get the error--> The content for this response was already consumed 


I am using requests version is '2.31.0'

```python
import requests

```

## System Information

Cell In[15], line 56
     53 if json_error==True:
     54     print('--------')
---> 56     print(response.text)
     57     print('--------')
     58     print('\n')

File ~\AppData\Local\anaconda3\Lib\site-packages\requests\models.py:923, in Response.text(self)
    920 content = None
    921 encoding = self.encoding
--> 923 if not self.content:
    924     return ""
    926 # Fallback to auto-detected encoding.

File ~\AppData\Local\anaconda3\Lib\site-packages\requests\models.py:894, in Response.content(self)
    891 if self._content is False:
    892     # Read the contents.
    893     if self._content_consumed:
--> 894         raise RuntimeError("The content for this response was already consumed")
    896     if self.status_code == 0 or self.raw is None:
    897         self._content = None

RuntimeError: The content for this response was already consumed

<!-- 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). -->


this is very urgent for me 

can library owner can respond?


Hello Alnisha,
I am willing to work on your issue. could you please give me Reproduction Steps so that I understand your issue clearly ? 
 Best Regards

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. There is no urgent unpaid support. Demanding someone help you urgently is not acceptable behavior
Document which exceptions request() might raise

Ask to document which exceptions request() might raise

I notice that the .[json function documents that it might raise](https://requests.readthedocs.io/en/latest/api/#requests.Response.json)  a `JSONDecodeError`.  This is very helpful for writing comprehensive error handling code around requests. I'm asking for that to be done for [the main interface](https://requests.readthedocs.io/en/latest/api/#main-interface) as well.

While [a list of exceptions](https://requests.readthedocs.io/en/latest/api/#exceptions) is provided in the documentation, it is not clear which exceptions will be returned by which methods. For example I don't think `JSONDecodeError` can be raised by `.get`. I tried to read the requests code to get a sense of which might be thrown from it, but it is a little challenging to follow as a first time reader.

As a newcomer to this project, I'm eager to contribute and address the mentioned issue. I'd like to inquire about the exceptions list mentioned in the documentation—is it exhaustive and does it encompass all possible exceptions? If so, I'm prepared to work on enhancing the documentation. My proposal is to not only update the main interface but also extend the coverage to other methods, aiming for consistency similar to what is currently done for the .json() function.

That would lead to a lot of code duplication in my opinion, apart from `requests.ReadTimeout` and `requests.JSONDecodeError` , all [request methods return an instance of the `Response` object](https://requests.readthedocs.io/en/latest/api/#exceptions), which can raise the [same exceptions](https://requests.readthedocs.io/en/latest/api/#exceptions).


I want to solve this issue @mjperrone , if this issue is still opened and kindly assign me this issue and provide me necessary required information
Max retries exceeded with url

Can explain me cause of this error and is possible avoid or solve it ?

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/PIDrive/Recordurbate/recordurbate/bot.py", line 81, in is_online
    r = requests.get(url)
  File "/usr/local/lib/python3.9/dist-packages/requests/api.py", line 73, in get
    return request("get", url, params=params, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/requests/api.py", line 59, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/requests/sessions.py", line 589, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python3.9/dist-packages/requests/sessions.py", line 703, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/requests/adapters.py", line 517, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='chaturbate.com', port=443): Max retries exceeded with url: /api/public/affiliates/onlinerooms/?wm=DkfRj&client_ip=request_ip&limit=500 (Caused by SSLError(SSLEOFError(8, 'EOF occurred in violation of protocol (_ssl.c:1123)')))


As described in the template, we won't be able to answer questions on this issue tracker. Please use [Stack Overflow](https://stackoverflow.com/)
Measure and report test coverage

This runs pytest within coverage, enables pytest-xdist to improve test run times, and reports the coverage on GitHub Actions for us.

This also ensures that the parallel mode coverage files are ignored and adds things to pytest configuration to make tox command simpler

I haven't had a chance to dig into the failure yet, but it's showing 26% coverage which seems _extremely_ low. I tried to go back to find [older examples of when codecov](https://github.com/psf/requests/pull/3920#issuecomment-285275742) was running and am seeing closer to 89% coverage. Do we possibly have something misconfigured?

Running in tox I get north of 80% as well but we're not running in tox on GitHub actions so that may be part of the problem

It looks like we're possibly hitting an issue with `coverage combine` similar to what's noted in https://github.com/nedbat/coveragepy/issues/1036.

We're generating 21 files for the 21 tests across 7 interpreters. From Ned's response it sounds like those combinations have subtle variances that may result in false flags for missing coverage? When running the tests locally without `parallel=True` and generating a single file it shows 87% like I'd expect. If I use `parallel = True` and don't use `combine`, we get the same results we're seeing in CI as if we're missing coverage data.

Have you used this workflow in other projects? If not, we might consider dividing coverage by interpreter or another partitioning strategy.

I mostly stole this from urllib3 and https://hynek.me/articles/ditch-codecov-python/ but maybe I missed something important
Wrong CA Certificates used in requests.Session.send

Bug in requests.sessions.py:

https://github.com/psf/requests/blob/b8be93a721792deeadd2f498b8f77cf610e7765f/src/requests/sessions.py#L579-L589

session.merge_environment_settings is called in session.request and not in session.send which means if users want to build their own prepared requests (see example below), the correct certificates file will not be used unless explicitly passed to send.

I believe these environment settings should be updated in session.send instead.

## Reproduction Steps

```python
import os
import requests

# Set CA certificates file to custom local file
os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

# Create request object
req = requests.Request(
    method="GET", # any method
    url="https://www.example_site.mydomain.com/path" # any url for which the default cert file does not have a cert for
)

with requests.Session() as s:
    respA = s.request( # Success: will use CA certificates from REQUESTS_CA_BUNDLE
        method=req.method,
        url=req.url
    )
    assert respA.status_code == 200
    
with requests.Session() as s:
    respB = s.send( # Success: will use CA certificates from REQUESTS_CA_BUNDLE if explicitly specified
        request=req.prepare(), verify=os.environ["REQUESTS_CA_BUNDLE"]
    )
    
    assert respB.status_code == 200
    
with requests.Session() as s:
    respC = s.send( # Error: Will try to use default CA certificates instead of those specified by REQUESTS_CA_BUNDLE
        request=req.prepare() 
    )
    
    assert respC.status_code == 200
```

## Expected Result

No output

## Actual Result

```
requests.exceptions.SSLError: HTTPSConnectionPool(host='https://www.example_site.mydomain.com/path', port=443): Max retries exceeded with url: /path (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:997)')))
```

## System Information

    $ python -m requests.help

```json
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "3.3.2"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.10.4"
  },
  "platform": {
    "release": "5.4.0-150-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.31.0"
  },
  "system_ssl": {
    "version": "30000020"
  },
  "urllib3": {
    "version": "2.2.1"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}
```


I can confirm I'm seeing this behavior when using prepared requests and `sessions.send()`, being forced to set `session.verify = os.environ['REQUESTS_CA_BUNDLE']` before `send()`.
('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

can anyone help me with the below error
Error occurred ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
I am using requests==2.28.2 version and while logging into tableau server using rest api the error is coming.
As I am first creating the session and then doing the post request.

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.
Fix CI

This PR will bring in a few changes to fix our CI suite. The release of `httpbin` 0.10.2 unblocks our test suite with Flask 3.0 which should fix the breakages in the last several months. In that window, our PyPy 3.8 build has broken on Windows due to https://github.com/pyca/cryptography/issues/10371. PyPy has dropped upstream support for both 3.7 and 3.8, so it seems more straight forward to follow them than try to patch around the cryptography issue.

We'll plan to deprecate both EoS PyPy runtimes with the next Requests release alongside CPython 3.7.

Updated Sphinx to the latest release as well due to us no longer meeting the minimum required version for readthedocs to do our preview build. I'll spot check the docs once that finishes, they appear to render normally with a local build.

Docs appear to be in good shape: https://requests--6641.org.readthedocs.build/en/6641/
A

<!-- Summary. -->

## Expected Result

<!-- What you expected. -->

## Actual Result

<!-- 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). -->

As described in the template, we won't be able to answer questions on this issue tracker. Please use [Stack Overflow](https://stackoverflow.com/)
requests Session and pool timeout.

Hi i want to know if it is possible for connections in session pool to have a timeout.
For example

```
import requests
import time

sess = requests.Session(pool_timeout=3)

sess.get("https://www.google.com")
time.sleep(4)
sess.get("https://www.google.com") # This creates a new connection and the previous is closed
```

I've found some answers that point to setting default_socket_options, but that doesn't seem to close sessions i always end up with this behaviour while logging.

```
import logging
logging.basicConfig(level=logging.DEBUG)

import requests

import time

import socket
from urllib3.connection import HTTPConnection

HTTPConnection.default_socket_options = ( HTTPConnection.default_socket_options + [
        (socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1),
        (socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 1),
        (socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 1),
        (socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 1)
        ]
)

url = 'https://www.google.com'

sess = requests.Session()

for x in range(2):
    data = sess.get(url)
    print(data)
    time.sleep(3)

```

This doesn't start a new https connection, nor it does tell me if any of the socket options above is doing anything.
```
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): www.google.com:443
DEBUG:urllib3.connectionpool:https://www.google.com:443 "GET / HTTP/1.1" 200 None
<Response [200]>


DEBUG:urllib3.connectionpool:https://www.google.com:443 "GET / HTTP/1.1" 200 None
<Response [200]>
```

Maybe i'm missing some concept, but those socket options do not say that after 1 second of not sending requests, the socket should be closed?

Thanks


As described in the template, we won't be able to answer questions on this issue tracker. Please use [Stack Overflow](https://stackoverflow.com/)
IPv6 address change for sequential gets

I'm not sure, if the following issue is caused by requests or one of the underlying libraries. 
The library [python-fritzhome](https://github.com/hthiery/python-fritzhome/) uses requests to connect to the HTTP interface of a router called FRITZ!Box. During sequential get calls, the IPv6 address is switched.
I already opened an [issue](https://github.com/hthiery/python-fritzhome/issues/92) for the mentioned library, but got no solution.

## Expected Result

All connections of the same session object are made using the same IPv6 address.

## Actual Result

The third get request uses a different IPv6 address (extract of a tcpdump record):
![grafik](https://github.com/psf/requests/assets/31780740/2833bf6a-0a23-44ed-97d8-8c639023adf5)

## Reproduction Steps

```python
import requests
import time

s = requests.Session()
rsp = s.get('http://fritz.box/login_sid.lua')
rsp.raise_for_status()
time.sleep(0.5)
rsp = s.get('http://fritz.box/login_sid.lua')
rsp.raise_for_status()
time.sleep(0.5)
rsp = s.get('http://fritz.box/login_sid.lua')
rsp.raise_for_status()
print(rsp.text.strip())
```

## System Information

Hardware and OS: Raspberry Pi 5, Raspberry Pi OS Lite 64 based on Debian 12

    $ python -m requests.help

```json
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "3.3.2"
  },
  "cryptography": {
    "version": "41.0.7"
  },
  "idna": {
    "version": "3.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.11.2"
  },
  "platform": {
    "release": "6.1.0-rpi8-rpi-2712",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "30100040",
    "version": "23.2.0"
  },
  "requests": {
    "version": "2.31.0"
  },
  "system_ssl": {
    "version": "300000b0"
  },
  "urllib3": {
    "version": "2.1.0"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": true
}
```

<!-- 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). -->


Removing the sleep calls did not change anything:
![grafik](https://github.com/psf/requests/assets/31780740/615a4144-ea6d-4eb8-9f7b-c37fa72391ea)

@Gezzo42 this is not a bug. It's not ideal that when looking up the DNS for a hostname we only ever use 1 address. It's also not clear why you consider this a bug. Even still, this can likely be reproduced with just `urllib3` and potentially even with _any_ http client in Python (aiohttp, httpx, etc.) If you want to pin to a given IP address, you will want to specify it yourself. These all seem to be local addresses.

To get the ideal behaviour, you likely want to ensure:
* The library you're using isn't disabling keep-alive
* The server you're communicating with supports keep-alive
* Anything you have between you and the server isn't preventing keep-alive.
feat: ability to custom `HTTPAdapter` instance variables while creating `Session`

Ability to custom `HTTPAdapter` instance variables while creating `Session`.

This project is under a feature freeze and it's not accepting changes like this. Thank you for thinking of us but we'll be closing this without merging 

Ok, that's fine, even I do think I will need this, I now have to apply temporary workarounds for this. If you change your mind, feel free to provide your feedback here.
Getting warning while running databricks cli command in azure devops

<!-- Summary. -->
Hello team,

i am using Databricks Cli for deployment of notebooks on azure and it is throwing below warning. Could you help me to resolve warning? Also i am using pip install --upgrade urllib3 chardet command to upgrade but still it is giving warning.
/usr/lib/python3/dist-packages/requests/__init__.py:87: RequestsDependencyWarning: urllib3 (2.2.0) or chardet (4.0.0) doesn't match a supported version!
  warnings.warn("urllib3 ({}) or chardet ({}) doesn't match a supported "

## Expected Result
 I want to ignore/resolve the warning.
<!-- What you expected. -->

## Actual Result
 It is throwing warning as below
/usr/lib/python3/dist-packages/requests/__init__.py:87: RequestsDependencyWarning: urllib3 (2.2.0) or chardet (4.0.0) doesn't match a supported version!
  warnings.warn("urllib3 ({}) or chardet ({}) doesn't match a supported "



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.
`params` might be misnamed?

<!-- Summary. -->

### Summary

Being a bit pedantic but isn't it that the `parameters` of a URL are a ";<parameters>" affair inside the path e.g. `https://example.com/document;language=english?documentID=5` ([RFC source](https://datatracker.ietf.org/doc/html/rfc3986#section-3.3) and [summary](https://stackoverflow.com/a/39294675)) and what Requests calls `params` is actually the `query`.. which I long have been calling the "querystring" thanks to my days of Classic ASP programming referencing the "query string" (https://www.w3schools.com/asp/coll_querystring.asp and https://en.wikipedia.org/wiki/Query_string).

[Documentation calls them part of the query string too](https://requests.readthedocs.io/en/latest/user/quickstart/#passing-parameters-in-urls).

<!-- What you expected. -->

### What you expected

Good question, maybe the keyword to be `query`? But I highly doubt there will be any aspiration to start renaming the library's keywords at this late stage in a way that would cause a breaking change (unless both were accepted and one was mapped to the other). Validation I guess that I am right (or a correction if I am wrong)?

Parameters is another common name for the parsed (not encoded) pieces of the query string. `params` are meant to be passed as a native python object (e.g., dictionary of string to string, sequence of tuples of length 2, etc). So if you parsed a query string into parameters on the server side, the client side would take parameters and encode them into the query string 

Edit to add: 

- https://www.botify.com/learn/basics/what-are-url-parameters#:~:text=URL%20parameters%20(also%20known%20as,by%20the%20'%26'%20symbol.
- https://rapidapi.com/blog/api-glossary/parameters/#:~:text=API%20parameters%20are%20the%20variable,present%20in%20the%20API%20endpoint.
- https://support.google.com/google-ads/answer/6277564?hl=en
- https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams
- https://docs.oracle.com/en/cloud/saas/marketing/eloqua-develop/Developers/GettingStarted/APIRequests/URL-parameters.htm
- https://sentry.io/answers/how-to-get-values-from-urls-in-javascript/
- https://www.w3docs.com/snippets/javascript/how-to-get-url-parameters.html

None of this is to say you're wrong and we're right, just that it's not uncommon for the query string to be called query parameters or parameters for short
Multipart/form-data requests creates mismatched boundaries between request body and headers

<!-- Summary. -->

## Expected Result
multipart/form-data requests should have the same boundary in the request content-type headers and request body:

Content-Type header: `multipart/form-data; boundary=bb8517293e3e961b2e7dfbd4e303fe56`
Boundary for request body: `--bb8517293e3e961b2e7dfbd4e303fe56`
## Actual Result
multipart/form-data requests have different boundaries in the request content-type headers and request body:

Content-Type header: `multipart/form-data; boundary=bb8517293e3e961b2e7dfbd4e303fe56`
Boundary for request body: `--42fdbee1e9d775f1239dda28331699a7`

## Reproduction Steps

```python
import requests
session = requests.session()

data = {
  "name": "test",
  "description": "test",
}
files = {'upload_file': open("yourfile.txt", "rb")}
req = session.post("https://example.com", files=files, data=data)

print("Request Headers: " + str(req.request.headers))
print("Request Body: " + str(req.request.body))
print("Status Code: " + str(req.status_code))
print("Response Headers: " + str(req.headers))
print("Response Body: " + str(req.text))
```

## System Information

    $ python -m requests.help

```json
{
  "chardet": {
    "version": "3.0.4"
  },
  "charset_normalizer": {
    "version": "2.1.0"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.10.7"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.31.0"
  },
  "system_ssl": {
    "version": "1010111f"
  },
  "urllib3": {
    "version": "1.26.11"
  },
  "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 cannot reproduce this at all. The only time the boundary tends to differ in the header from what's in the body is when the user overrides the Content-Type header manually.

In the future, please search **closed and** open issues before creating new ones that are duplicates.
Fix #6628 - JSONDecodeError are not deserializable

See issue #6628 for full bug-report

-----

requests.exceptions.JSONDecodeError are not deserializable: calling `pickle.dumps` followed by `pickle.loads` will trigger an error.

This is particularly a problem in a process pool, as an attempt to decode json on an invalid json document will result in the entire process pool crashing.

This is due to the MRO of the `requests.exceptions.JSONDecodeError` class: the `__reduce__` method called when pickling an instance is not the one from the JSON library parent: two out of three args expected for instantiation will be dropped, and the instance can't be deserialised.

By specifying in the class which parent `__reduce__` method should be called, the bug is fixed as all args are carried over in the resulting pickled bytes.

We need to fix the CI but this should be set to go once that's resolved.

closing and re-opening to trigger a new build

Looks like tests are passing now, I'll go ahead and merge. Thanks again, @Tarty!

Happy to contribute, thanks for merging the fix in!
Kenneth Reitz, Take care of yourself.

I am also the author of a popular open-source library (MagicIndicator, 10K stars). Similarly, I have experienced manic depression (bipolar disorder), but I have overcome it and now lead a normal, positive life. I hope you recover soon too. Keep fighting!

Closing this issue as it's not an issue in Requests. Please consider avenues of messaging folks directly, opening GitHub issues pings thousands of unrelated people.
Unintended Leak Of Proxy-Authorization Header In Requests

**Describe the bug**
While scanning my Django application's manifest file using Vulert for vulnerability checks, I identified an issue associated with your package.

**Reference**
Upon conducting a vulnerability scan, the following references were identified:
Vulert Scan Report: [Vulert Report](https://vulert.com/vuln-scan/list/a1524f3e-61e3-409c-8630-9134c5b84eea)
CVE Reference: [CVE-2023-32681](https://vulert.com/vuln-db/pypi-requests-70669)