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, jimr, martin.panter
Date 2015-03-01.01:26:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <DBF5286C-CD7C-4561-94C5-1EA5E8779ADC@gmail.com>
In-reply-to <1425139994.56.0.126460216247.issue23539@psf.upfronthosting.co.za>
Content
> My feeling is that '' implies "present but empty" (so should have a content-length set to zero), whereas None implies "missing" (so should only have a content-length header set to zero if the method is expecting a body.

Although I understand your thinking here, I think that bodies that are either None or empty string should be treated identically. Whether or not the Content-Length header is set should be dependent on the method used.

From a client standpoint, there’s no difference between sending a body with a value of None and an empty string (the latter will get further down the call stack, but no data is actually sent over the wire).

Likewise from the server standpoint, there is no functional difference between a missing or empty body. However, there’s still the possibility of unexpected behaviour due to the inclusion of a Content-Length header for a method not expecting it.

In light of that, I think that HTTPConnection(‘example.com’).request(‘GET’, ‘/‘, ‘’) and HTTPConnection(‘example.com’).request(‘GET’, ‘/‘) should result in identical headers with no Content-Length set.

If someone /really/ wants to set the Content-Length header for a method that doesn’t expect it, they still have the ability to do so: HTTPConnection(‘example.com’).request(‘GET’, ‘/‘, ‘’, {‘Content-Length’: 0}). However, if the default behaviour is to include the Content-Length header for an empty string, the user then has to change what they’re sending to be None instead of empty string even though they should be functionally equivalent.
History
Date User Action Args
2015-03-01 01:26:37demian.brechtsetrecipients: + demian.brecht, martin.panter, jimr
2015-03-01 01:26:36demian.brechtlinkissue23539 messages
2015-03-01 01:26:35demian.brechtcreate