You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue a suggestion for handling partial elements of issues #1737 and #2086 (#1774 and others too). I'm bringing this up in a separate ticket because it is a specific fix for multiple tickets and I am willing to write a PR for it in requests3 and requests2. (i would have just gone and generated a PR, but I can't figure out what the actual master for requests3 actually is)
my proposal is to do the following (some of which have already been discussed as possibilities):
alter get_encoding_from_headers()
replace the default value of get_encoding_from_headers with None when "text" is in the content_type header. currently this is "ISO-8859-1"
extend build_response and Response to additionally stash the header decoding in response.detected_encoding. this will allow the detected value to remain on the response object if response.encoding is changed by the consumer.
add Response.text_encoding property
add a text_encoding property to Response , which offloads some of the logic now in text, and will return "ISO-8859-1"
alter Response.text to use the new .text_encoding attribute
update the text property to use the new .text_encoding attribute. this just ties together all the above.
Goals
The goal of these changes is to positively identify situations where no response encoding was declared by the server. The backwards incompatibility is that None will now be returned when inspecting response.encoding when there is no encoding for the response - however the effective encoding used to generate .text will be available in response.text_encoding .
This still maintains compliance with RFC 2616, because .text will still interpret the lack of a declared encoding as having the required default charset of ISO-8859-1. This simply allows developers to know when ISO-8859-1 is being used in a default or explicit manner.
This approach doesn't address all aspects of those issues or close those tickets, but it offers a solution to many of the needs and concerns with some minor changes.
The text was updated successfully, but these errors were encountered:
jvanasco
changed the title
replace get_encoding_from_headers default with None
replace get_encoding_from_headers default with NoneMay 10, 2019
This issue a suggestion for handling partial elements of issues #1737 and #2086 (#1774 and others too). I'm bringing this up in a separate ticket because it is a specific fix for multiple tickets and I am willing to write a PR for it in requests3 and requests2. (i would have just gone and generated a PR, but I can't figure out what the actual master for requests3 actually is)
my proposal is to do the following (some of which have already been discussed as possibilities):
alter
get_encoding_from_headers()
replace the default value of
get_encoding_from_headers
withNone
when "text" is in the content_type header. currently this is "ISO-8859-1"https://github.com/kennethreitz/requests/blob/c501ec986daa4961cd9dee370b5d45ff2e524b37/requests/utils.py#L492-L493
add
Response.detected_encoding
attributeextend
build_response
andResponse
to additionally stash the header decoding inresponse.detected_encoding
. this will allow the detected value to remain on the response object ifresponse.encoding
is changed by the consumer.add
Response.text_encoding
propertyadd a
text_encoding
property toResponse
, which offloads some of the logic now intext
, and will return "ISO-8859-1"https://github.com/kennethreitz/requests/blob/c501ec986daa4961cd9dee370b5d45ff2e524b37/requests/models.py#L835-L858
alter
Response.text
to use the new.text_encoding
attributeupdate the
text
property to use the new.text_encoding
attribute. this just ties together all the above.Goals
The goal of these changes is to positively identify situations where no response encoding was declared by the server. The backwards incompatibility is that
None
will now be returned when inspectingresponse.encoding
when there is no encoding for the response - however the effective encoding used to generate.text
will be available inresponse.text_encoding
.This still maintains compliance with RFC 2616, because
.text
will still interpret the lack of a declared encoding as having the required default charset ofISO-8859-1
. This simply allows developers to know whenISO-8859-1
is being used in a default or explicit manner.This approach doesn't address all aspects of those issues or close those tickets, but it offers a solution to many of the needs and concerns with some minor changes.
The text was updated successfully, but these errors were encountered: