This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author demian.brecht
Recipients demian.brecht, martin.panter, orsenthil
Date 2015-02-13.15:46:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Thanks for the review Martin, I've addressed your comments.

> The length of an encoded Latin-1 string should equal the length of the unencoded text string, since it is a one-to-one character-to-byte encoding.
Once in a while, I want to stop what I'm doing, put my head in my hands
and think to myself "how did that escape me"?! Of course you're right
and thanks for the catch. I've reverted the handling to how it was being
done in the previous patch.

> Though I’m not particularly excited by silently Latin-1 encoding text bodies in the first place.
Truth be told, I'm more fond of only accepting pre-encoded byte strings
as input. However, that backwards incompatible change would likely break
many things. Request bodies can currently be strings, byte strings,
iterables or file objects. In the cases of string and file objects,
encoding is already supported. The change I made makes handling
iterables consistent with the other accepted data types.

I'm not sure why, but the auto-encoding of the raw string input object
was being done higher up in the general use case callstack
(Lib/http/ I've moved this handling to send() for
consistency with the auto-encoding of other input types. This also
ensures consistent behavior between calling request() with a string body
and calling send() directly.
File name Uploaded
list_content_length_3.patch demian.brecht, 2015-02-13.15:46:57
Date User Action Args
2015-02-13 15:46:57demian.brechtsetrecipients: + demian.brecht, orsenthil, martin.panter
2015-02-13 15:46:57demian.brechtlinkissue23350 messages
2015-02-13 15:46:57demian.brechtcreate