Lighttpd

Should be fixed in r2278. Just for reference, in your case you consider this a security issue since it allows for unwanted disclosure of information.
Not sure if we are going to handle it as one, but I guess it should be at least noted.

stbuehler committed the fix and didn't close this ticket as trac was broken, so I'm doing that now. All kudos to him in any case. :p

Patch(es) reverted in 1.4.x (r2362) - too many regressions came up.
See commit message for more details.

We are not sure yet what to do, maybe we won't fix this at all.

con->request.uri is url-encoded and includes URI path and query-string
con->uri.path has been url-decoded and path has been simplified/normalized
con->uri.query is url-encoded

mod_rewrite operates on con->request.uri, meaning that there might be ways to subvert rewrite rules by url-encoding parts of it, since most rewrite rules will be against a normalized path and query string.

Perhaps the solution is to normalize the url-encoding of con->request.uri for rewrite rules, but there might still be complexities involved in virtual paths containing '.' or '..', PATH_INFO, whether or not to decode %2F ('/') in path and/or query-string parts, ...

I propose normalizing the url-encoding, including decoding %2F to '/'. Decoding %2F to '/' potentially loses some info in PATH_INFO and query string, but is a more secure default giving most people what they would expect. Maybe we could additionally provide a config switch to skip decode of %2F for the regex input.

Note: I am suggesting decoding con->request.uri temporarily for the regex match. If we were to normalize url-encoding at the start of the request, I would suggest leaving %2F url-encoded at that point of normalization. We might still decode %2F for regex matching, unless a new config flag were set.

(While discussing url-decoding here, please see url-encoding discussion of regex back-reference matches in #911)

Applied in changeset 3eb7902e10ba75b3f2eb159e244d0d8e5037ccd2.