Author demian.brecht
Recipients demian.brecht, martin.panter, orsenthil
Date 2015-02-13.05:50:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1423806655.55.0.643557359907.issue23350@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks for the clarification Martin. After giving this some further thought, I think that the best way to go is to /only/ calculate and add the Content-Length header if each element in the list or tuple is pre-encoded. If it's mixed or only strings, then there are one of three options:

1. Don't try to compute the Content-Length automatically as encoding may change the number of bytes being sent across as the body (which is what the Content-Length represents)
2. Encode the entire body twice, once during the computation of the Content-Length and again on the fly as the body is being written to the socket. This will incur 2x the CPU cost, which can be costly if the body is sufficiently large.
3. Encode the entire body once and store it in memory. Given body sizes can be quite large, I don't think that duplicating the body would be a good approach.

The attached patch uses option 1 in order to not add any CPU or memory cost to the operation, but still fix the Content-Length issue as reported. I've also updated the docs to indicate as much.
History
Date User Action Args
2015-02-13 05:50:56demian.brechtsetrecipients: + demian.brecht, orsenthil, martin.panter
2015-02-13 05:50:55demian.brechtsetmessageid: <1423806655.55.0.643557359907.issue23350@psf.upfronthosting.co.za>
2015-02-13 05:50:55demian.brechtlinkissue23350 messages
2015-02-13 05:50:55demian.brechtcreate