[issue22467] Lib/http/server.py, inconsistent header casing

2014-09-22 Thread DS6

New submission from DS6:

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.)

--
components: Library (Lib)
messages: 227324
nosy: DS6
priority: normal
severity: normal
status: open
title: Lib/http/server.py, inconsistent header casing
versions: Python 3.4

___
Python tracker 
<http://bugs.python.org/issue22467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22467] Lib/http/server.py, inconsistent header casing

2014-09-22 Thread DS6

DS6 added the comment:

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...

--

___
Python tracker 
<http://bugs.python.org/issue22467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22467] Lib/http/server.py, inconsistent header casing

2014-09-23 Thread DS6

DS6 added the comment:

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.

--

___
Python tracker 
<http://bugs.python.org/issue22467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22467] Lib/http/server.py, inconsistent header casing

2014-09-23 Thread DS6

DS6 added the comment:

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.

--

___
Python tracker 
<http://bugs.python.org/issue22467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22467] Lib/http/server.py, inconsistent header casing

2014-09-23 Thread DS6

DS6 added the comment:

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.

--

___
Python tracker 
<http://bugs.python.org/issue22467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com