Python 3.6.0a2 has been released this week.  I guess, we need to speed up a bit.  I really would like to see this issue fixed in 3.6.0 final.

I updated Demian's patch to match the current Python sources, see the attachment.  I also addressed the issue in urllib.request.  It turned out that this was a little bit more involved then just removing the corresponding if statement from AbstractHTTPHandler.do_request_() as suggested above: if the Content-Length has been added by the lib, a caller of urllib might assume to find that header also to be set in the Request object afterwards.  At least, some tests do.

But I still believe, urllib.request should refrain from trying to calculate the content length itself, but rather rely on http.client for this, because it is crucial that the interpretation of the various body representations (buffer, file, iterable) while calculating this length matches the code in http.client that reads the body when sending it to the server.

So, I amended Demian's patch as follows:

1. change the helper _get_content_length() in http.client to a static method of HTTPConnection in order to allow urllib.request to call it.

2. review get_content_length(), there where a few issues in special cases.

3. add an optional argument encode_chunked to http.client.HTTPConnection.request().  If set to True, HTTPConnection will do the chunk encoding also if the Transfer-Encoding header is set.  This is needed, because urllib.request now sets all required headers in the request, including Transfer-Encoding if needed.  But does not handle the chunk encoding itself.

4. if the request has a non-empty body and Content-Length is not set, urllib.request.AbstractHTTPHandler calls http.client.HTTPConnection.get_content_length to calculate the content length.  If this returns None, it sets the Transfer-Encoding: chunked header.