Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

recorder: use a case-insensitive HTTP headers check #728

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ptalbert
Copy link

_recorder._remove_default_headers() does a case-sensitive check for HTTP header field names are case insensitive. The result is that for example, a lower-case 'content-type' field will not be removed. Later, when _add_from_file tries to load the data using RequestsMock.add(), a RuntimeError exception will be raised when it finds the 'content_type' kwarg was passed and 'content-type' is in the 'headers' kwargs.

Fix this by simply having _remove_default_headers() do a case-insensitive check.

_recorder._remove_default_headers() does a case-sensitive check for
HTTP header field names are case insensitive. The result is that for
example, a lower-case 'content-type' field will not be removed. Later,
when _add_from_file tries to load the data using RequestsMock.add(), a
RuntimeError exception will be raised when it finds the 'content_type'
kwarg was passed and 'content-type' is in the 'headers' kwargs.

Fix this by simply having _remove_default_headers() do a
case-insensitive check.

Signed-off-by: Patrick Talbert <[email protected]>
Recorder._on_request does not set the content_type parameter when
creating a new Response instance. When content_type is not set the
Response.__init__ will always set the value to "text/plain". This means
the recording file is always written with that content type and when
responses are replayed they may not have their original content-type
header value.

For example, the python-gitlab package expects the response header
content type to be 'application/json' but this information is in the
recording and playing it back will fail.

Fix this by having _on_request() pass in the content_type of the
requests_response.header.

Signed-off-by: Patrick Talbert <[email protected]>
Comment on lines +157 to +158
if content_type := requests_response.headers.get("content-type"):
response_params["content_type"] = content_type
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to have a test covering this change and validating that the Response that is created from the recording has the right parameters/headers.

@andrew-womeldorf-smar
Copy link

This should also resolve #724

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants