homepage

Inconsistent casing, such as "Content-type" vs "Content-Type", "Content-Length" vs "Content-length", while technically not breaking any RFC or other HTTP-related rules (headers are case-insensitive, after all), can occasionally cause problems when attempting to retrieve already-set headers from http.server.BaseHTTPRequestHandler._headers_buffer (in my situation specifically, trying to retrie the Content-Type header in the sendfile method in an extended BaseHTTPRequestHandler class). This happens a lot in the file and I wouldn't be surprised if the problem were to crop up in other places as well.
I'm a new user of Python, so despite having searched for an answer to this problem, if there's a case-insensitive way to obtain items from a list and I'm just daft, please feel free to point me in the right direction, though I feel that the casing should be corrected regardless for consistency and optimization sake.
(Aside: I would try to publish a patch along with this issue report with the casing issues fixed, but I'm not too knowledgeable about versioning and stuff and would have no idea where to start.)

First thing (and the easiest is), if you find inconsistent casing in http/server.py itself, then make it consistent in your patch against cpython default branch (from hg.python.org). Make it Content-Length and Content-Type in your patch.
Next part is while receiving the request with these headers, the client and server should store it in case-insensitive dict (there is open request and patch, which can churn up again and we can fix it as part of that issue).

Erp, *retrieve, and I meant copyfile, not sendfile. I'm tired.
Very quick reply, by the way.
I suppose I forgot to mention that _headers_buffer is for sending headers, not for receiving them. As far as I can read, the received header information is already case-insensitive, due to email.message.Message being used.
It also occurs to me that the _headers_buffer field probably wasn't designed to be directly accessed, seeing as how it's usually flushed immediately after being modified...

It also has a leading underscore, which means it is a "private" interface and you use it at your own risk.
To the extent that there is an actionable issue here, it is a duplicate of issue 12455. email.message already provides case insensitive header retrieval, by the way.

Whoa, I thought " - no selection - " would not change the set values, but I guess I was wrong. I have no idea what I'm doing, sorry.

Yeah, I was aware it's used for getting the request headers. It's strange that it's not used for setting reply headers, though the casing really doesn't cause any problems for the current implementation and really only affects fringe cases like mine and that fellow in issue #12455.
I suppose it would simply be wiser to rewrite my own code a bit instead of relying on private fields, since I am actually extending with my own classes instead of wholly relying on the std libs.
I appreciate the post, David, I was not aware this issue had been brought up before; I did actually search for related issues but I guess I didn't see that one.
Whoa, I thought " - no selection - " would not change the set values, but I guess I was wrong.
...And apparently duplicate messages are pruned.
I have no idea what I'm doing, sorry.

Oh... It showed that the message had been created but it really hadn't, because I had the Status field set to " - no selection - " so now I've posted two (three) times.
Good lord I am sickeningly bad at this. I'll just stop posting now.

Don't worry about it :) The roundup UI isn't terrible, but it is far from perfect.