Alex Raitz alex.ra...@gmail.com 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
Phillip J. Eby p...@telecommunity.com 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
Alex Raitz alex.ra...@gmail.com 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
Phillip J. Eby p...@telecommunity.com 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
Alex Raitz alex.ra...@gmail.com 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
Changes by Éric Araujo mer...@netwok.org:
--
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
Phillip J. Eby p...@telecommunity.com 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
