Re: [issue2551023] '-' in environment varibale
"John P. Rouillard" <[email protected]>
| Newsgroups | gmane.comp.bug-tracking.roundup.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Cédric, In message <[email protected]>, =?utf-8?q?C=C3=A9dric_Krier?= writes: >I use the wsgi_handler instead of roundup-server. And I can not get >HTTP_X-REQUESTED-WITH set in environment because WSGI server convert all >'-' into '_'. What server are you using? That translation of '-' to _' is not right/supported according to mod_wsgi or wsgi docs. It also seriously breaks the compatibility with CGI. >So the X-Requested-With header becomes HTTP_X_REQUESTED_WITH. But >roundup-server use HTTP_X-REQUESTED-WITH key. HTTP_X-REQUESTED-WITH is the correct form as the header is: X-REQUESTED-WITH Do you see the same mangling with X-Forward-Host or other http headers? >I think roundup-server behavior should be normalized with other WSGI >server and not use '-' in HTTP_*. >I could not find in PEP3333 that '-' should be converted into '_' for >HTTP_. There is only a reference to server-defined variables. > >https://www.python.org/dev/peps/pep-3333/#environ-variables Wow that seems wsgi is seriously broken. It is not what is documented. From mod_wsgi: https://modwsgi.readthedocs.io/en/develop/release-notes/version-4.3.0.html it says in part: bugs fixed: Under Apache 2.4, when creating the environ dictionary for passing into access/authentication/authorisation handlers, the behvaiour of Apache 2.4 as it pertained to the WSGI application, whereby it blocked the passing of any HTTP headers with a name which did not contain just alphanumerics or ‘-‘, was not being mirrored. This created the possibility of HTTP header spoofing in certain circumstances. Such headers are now being ignored. and under features: In Apache 2.4, any headers with a name which does not include only alphanumerics or ‘-‘ are blocked from being passed into a WSGI application when the CGI like WSGI environ dictionary is created. This is a mechanism to prevent header spoofing when there are multiple headers where the only difference is the use of non alphanumerics in a specific character position. This protection mechanism from Apache 2.4 is now being restrospectively applied even when Apache 2.2 is being used and even though Apache itself doesn’t do it. This may technically result in headers that were previously being passed, no longer being passed. The change is also technically against what the HTTP RFC says is allowed for HTTP header names, but such blocking would occur in Apache 2.4 anyway due to changes in Apache. It is also understood that other web servers such as nginx also perform the same type of blocking. Reliance on HTTP headers which use characters other than alphanumerics and ‘-‘ is therefore dubious as many servers will now discard them when needing to be passed into a system which requires the headers to be passed as CGI like variables such as is the case for WSGI. While it does not say that the - is preserved, not saying it's converted to _ would seem a massive oversight. Also: https://wsgi.readthedocs.io/en/latest/definitions.html says: HTTP_ Variables Variables corresponding to the client-supplied HTTP request headers (i.e., variables whose names begin with HTTP_). The presence or absence of these variables should correspond with the presence or absence of the appropriate HTTP header in the request. which is the same as in your cite of: https://www.python.org/dev/peps/pep-3333/#environ-variables The names for the http request headers are most definitely '-' separated. In cgi mode, the vars are precisely: HTTP_<uppercase version of http header field name> and that is exactly how the vars will be presented to the application. Tom any ideas here? You have the most wsgi experience. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. _______________________________________________ Roundup-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/roundup-devel