From cd4a7a69419e4890dc53f6daa5fcd572f1ba7015 Mon Sep 17 00:00:00 2001
From: Noa Levi <275430404+lphuc2250gma@users.noreply.github.com>
Date: Tue, 12 May 2026 14:14:12 +0000
Subject: [PATCH] docs: clarify Session.request verify parameter default
 behavior

The docstring claimed verify defaults to True, but the parameter
actually defaults to None and is merged with Session.verify (which
defaults to True). Document the real precedence so users tracking
down CA-bundle issues can see where the value comes from.
---
 src/requests/sessions.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/requests/sessions.py b/src/requests/sessions.py
index 8f13887d18..951225136c 100644
--- a/src/requests/sessions.py
+++ b/src/requests/sessions.py
@@ -606,8 +606,9 @@ def request(
             content. Defaults to ``False``.
         :param verify: (optional) Either a boolean, in which case it controls whether we verify
             the server's TLS certificate, or a string, in which case it must be a path
-            to a CA bundle to use. Defaults to ``True``. When set to
-            ``False``, requests will accept any TLS certificate presented by
+            to a CA bundle to use. When left as ``None`` (the default), the value of
+            :attr:`Session.verify` is used, which itself defaults to ``True``. When
+            set to ``False``, requests will accept any TLS certificate presented by
             the server, and will ignore hostname mismatches and/or expired
             certificates, which will make your application vulnerable to
             man-in-the-middle (MitM) attacks. Setting verify to ``False``