Some places in the code it is an email.message.Message object.  Some places it is a simple dictionary.  In one place (FTP), it is a string with embedded newlines.

I'm not sure what should be done about this situation, but it looks like a bug magnet, and it makes it pretty much impossible to document the data type.

@Demian I believe this maybe of interest to you.

@R. David Murray

Is this issue still valid? Running 3.6 it seems that http and ftp are consistent at any rate (http returns http.client.HTTPMessage and ftp returns email.message.Message). If it's still an issue, could you please elaborate?

There has been considerable rewriting of the header handling code since I filed this.  I would not be surprised if the issue is no longer valid.  If you want to double check, look for the places that the headers attribute is created in the various handlers.  Otherwise you can just close this as out of date.

>>> urlopen('https://example.com').info()
<http.client.HTTPMessage object at 0x111528da0>
>>> urlopen('http://example.com').info()
<http.client.HTTPMessage object at 0x111528be0>
>>> urlopen('ftp://speedtest.tele2.net').info()
<email.message.Message object at 0x111531080>
>>> urlopen('file:///path/to/setup.py').info()
<email.message.Message object at 0x111528f60>

I've taken a look at the rest of the handlers in urllib.request and they all build headers consistently with email.message_from_string().

Closing as out of date.