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 berker.peksag, demian.brecht, martin.panter, orsenthil, r.david.murray, serhiy.storchaka
Date 2015-03-23.00:40:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1427071217.56.0.3661839356.issue23350@psf.upfronthosting.co.za>
In-reply-to
Content
@Serhiy:
> Content-Length shouldn't be calculated for lists, tuples, and other non-bytes-compatible sequences.

I'd agree with this if it wasn't relatively trivial to calculate. There's no reason that I can think of to exclude the auto-generated Content-Length header for data types for which the size is known.


@Martin:
> Technically I don’t think there is a bug.

The bug is that the Content-Length header is currently added for bodies that are lists and tuples and the value is incorrect. For example:

con.request('POST', '/', ['aaa', 'bbb', 'ccc'])

results in 

Host: example.com
Accept-Encoding: identity
Content-Length: 3


@David:
> Since the latter cannot be done reliably unless we know the list or tuple is all bytes, I propose that we don't do it at all (since I'd like to see iterables of text strings supported).

The patch here adds support for iterables of text strings (as well as iterables comprised of both bytes and strings). Content-Length can be computed reliably as the size of a latin1-encoded string will be identical to the original string.
History
Date User Action Args
2015-03-23 00:40:17demian.brechtsetrecipients: + demian.brecht, orsenthil, r.david.murray, berker.peksag, martin.panter, serhiy.storchaka
2015-03-23 00:40:17demian.brechtsetmessageid: <1427071217.56.0.3661839356.issue23350@psf.upfronthosting.co.za>
2015-03-23 00:40:17demian.brechtlinkissue23350 messages
2015-03-23 00:40:17demian.brechtcreate