The comment about urllib.request forcing .title() is consistent with 'Content-Length' and 'Content-Type' in the docs but puzzling and inconsistent given that in 3.3, header names are printed .capitalize()'ed and not .title()'ed and that has_header and get_header *require* the .capitalize() form and reject the .title() form.

import urllib.request
opener = urllib.request.build_opener()
request = urllib.request.Request("http://example.com/", headers =
        {"Content-Type": "application/x-www-form-urlencoded"})
opener.open(request, "1".encode("us-ascii"))
print(request.header_items(),
      request.has_header("Content-Type"),
      request.has_header("Content-type"),
      request.get_header("Content-Type"),
      request.get_header("Content-type"), sep='\n')
>>> 
[('Content-type', 'application/x-www-form-urlencoded'), ('Content-length', '1'), ('User-agent', 'Python-urllib/3.3'), ('Host', 'example.com')]
False
True
None
application/x-www-form-urlencoded

Did .title in 2.7 urllib2 request get changed to .capitalize in 3.x urllib.request (without the examples in the doc being changed) or is request inconsistent within itself?

Cal did not the 2.7 code exhibiting the problme, but when I add this code in 3.3, the output start as shown.

request.add_header('Content-MD5', 'xxx')
print(request.header_items())
#
[('Content-md5', 'xxx'), ...

So is 3.3 sending 'Content-Md5' or 'Content-md5'

My guess is the former, as urllib.request has the same single use of .title in .do_open as Cal quoted. The two files also have the same three uses of .capitalize in .add_header, .add_unredirected_header, and .do_request. So it seems that header names are normalized to .capitalize on entry and .title on sending, or something like that. Ugh. Is there any good justification for this?

I do not see anything in the doc about headers names being normalized either way or about the requirements of has_/get_header. If the behavior were consistent and the same since forever, then I would say the current docs should be improved and a change would be an enhancement request. Since the behavior seems inconsistent, I am more inclined to think there is a bug.

I realize that this message expands the scope of the issue, but it is all about the handing of header names in requests.