On 01.01.2014 18:26, Stefan Fritsch wrote: > Am Mittwoch, 1. Januar 2014, 14:06:17 schrieb Graham Leggett: >>> Maybe making ap_regname() accept an optional prefix string that >>> is >>> prepended to each name would be a good idea? >>> >>> >>> >>> Maybe the use in <LocationMatch> and friends should add some >>> prefix to the names? Like "m_" or "match_" or "m:"? This would >>> make it more difficult to shoot oneself in the foot by allowing a >>> remote attacker to set env variables that have some special >>> meanings elsewhere in httpd (or in an executed cgi script). >>> And/or maybe these values should be filtered out again when >>> exporting them to cgi env variables? >> I wondered about this, on one hand it is nice to be able to set any >> variable, but on the other hand there is a lot of safety in >> preventing someone from being able to shadow an existing variable. >> I had "MATCH_FOO" in mind originally. > > I am in favor of adding a prefix. If there are important use cases for > setting arbitrary variables, one could (later) add a special opt-in > mechanism, e.g. using "noprefix:foo" in the regex leads to variable > "foo" without the prefix being set.
+1, mandatory prefix for now, optional configurability. Default should be with prefix. Of your three examples I like "match_" best. "m_" might be less likely for future conflicts, "m:" looks good, but I don't know whether then using the variable name in other config directives could lead to problems because of the colon in the name. Thanks for pushing this nice enhancement! Regards, Rainer
