Hi KSM team,
While working with the Keeper Secrets Manager SDK, we encountered an issue where the SDK raises a requests.HTTPError without attaching the actual HTTP response object to the exception. This leads to downstream failures when consuming code attempts to inspect the .response attribute — for example, in logging or retry logic.
🧱 Problem in the SDK
In core.py, line 673:
raise requests.HTTPError(f"Status Code: {rs.status_code}{reason}{message}")This raises an HTTPError without including the response object, leaving e.response as None.
⚠️ Why This Is Problematic
The requests.HTTPError exception is intended to wrap the actual HTTP response — even though response is optional in the constructor.
For example, the following pattern is common and expected:
raise requests.HTTPError("Something went wrong", response=response_obj)Without the response parameter, client code relying on e.response.status_code, e.response.text, or e.response.headers will fail with AttributeError.
📚 Supporting Evidence from requests
1. Response.raise_for_status() usage
raise HTTPError(http_error_msg, response=self)
The library always includes the response object.
2. RequestException class definition
The core of the exception hierarchy documents the intent directly:
class RequestException(IOError):
"""There was an ambiguous exception that occurred while handling your
request.
"""
def __init__(self, *args, **kwargs):
"""Initialize RequestException with `request` and `response` objects."""
response = kwargs.pop("response", None)
self.response = response
self.request = kwargs.pop("request", None)
if response is not None and not self.request and hasattr(response, "request"):
self.request = self.response.request
super().__init__(*args, **kwargs)This shows that requests is designed for the response object to be present and inspectable.
✅ Recommended Fix
Please change:
raise requests.HTTPError(f"Status Code: {rs.status_code}{reason}{message}")to:
raise requests.HTTPError(f"Status Code: {rs.status_code}{reason}{message}", response=rs)This will ensure better compatibility with logging systems, retry handlers, and any code using standard requests exception handling patterns.
Hi KSM team,
While working with the Keeper Secrets Manager SDK, we encountered an issue where the SDK raises a
requests.HTTPErrorwithout attaching the actual HTTP response object to the exception. This leads to downstream failures when consuming code attempts to inspect the.responseattribute — for example, in logging or retry logic.🧱 Problem in the SDK
In
core.py, line 673:This raises an
HTTPErrorwithout including theresponseobject, leavinge.responseasNone.The
requests.HTTPErrorexception is intended to wrap the actual HTTP response — even thoughresponseis optional in the constructor.For example, the following pattern is common and expected:
Without the
responseparameter, client code relying one.response.status_code,e.response.text, ore.response.headerswill fail withAttributeError.📚 Supporting Evidence from
requests1.
Response.raise_for_status()usageThe library always includes the response object.
2.
RequestExceptionclass definitionThe core of the exception hierarchy documents the intent directly:
This shows that
requestsis designed for theresponseobject to be present and inspectable.✅ Recommended Fix
Please change:
to:
This will ensure better compatibility with logging systems, retry handlers, and any code using standard
requestsexception handling patterns.