Alex Raitz added the comment:
I had previously tested it against simple_server. However, in reviewing my
test, I realized that you are correct that wsgiref headers is not misbehaving.
It appears that in simple_server, the values of remote-user and remote_user
both end up in HTTP_REMOTE_USE
Phillip J. Eby added the comment:
You say it "would" do this. Have you actually *tested* it?
Looking at the code in wsgiref again, I don't think it does what you think it
does. The '_' substitution is done to keyword arguments for header
*parameters* only; it's not done to header *names*.
Alex Raitz added the comment:
Per the first line of my previous comment, please ignore HTTP_REMOTE_USER.
The risk is that if the proxy does not place the user-supplied
'remote-user=VALUE1' before the proxy-supplied 'REMOTE_USER=VALUE2', wsgiref
will overload REMOTE_USER with the value of REMO
Phillip J. Eby added the comment:
I'm still baffled. How does this matter to anything?
The HTTP headers you describe would end up in an HTTP_REMOTE_USER environment
variable, with no impact on REMOTE_USER. REMOTE_USER could only be set by an
actual web server, not via an HTTP header.
So I
Alex Raitz added the comment:
Yes, I was referring to REMOTE_USER, apologies for the conflation with
HTTP_REMOTE_USER, which was one of the HTTP headers that a proxy which we were
testing was setting.
The customer that reported this issue to us was using FireFox with Tamper Data
to set REMOT
Phillip J. Eby added the comment:
I don't understand. HTTP_REMOTE_USER is not the name of a standard CGI
variable - it's REMOTE_USER.
It would help if you could show code for what client/proxy/server combination
has this problem, what happens when that code runs, and what you want to happen
Changes by Éric Araujo :
--
components: +Library (Lib) -Extension Modules
stage: -> needs patch
title: WSGIREF - REMOTE_USER and REMOTE-USER collision -> REMOTE_USER and
Remote-User collision in wsgiref
type: security -> behavior
versions: +Python 3.1, Python 3.2 -Python 2.6
_
