Lighttpd

One possibility: lighttpd sets the non-standard variable REQUEST_URI with the unencoded URI. You can re-split that into path and path_info in your application and then do a modified url-decode.

PATH_INFO is defined in the CGI spec to not be url-encoded.

As an alternative to get the information you seek, lighttpd provides REQUEST_URI (non-standard) along with standard CGI variables. The REQUEST_URI contains the raw request URI, before any url-decoding has been done, and before any information has been discarded, such as the distinction between '/' and '%2F' in the request.

To determine PATH_INFO, lighttpd url-decodes the URI, and then normalizes a path to the filesystem. "." and ".." URL path segments are resolved in the virtual path, and multiple consecutive slashes (e.g. "////") are reduced to a single slash. This normalized virtual URL path is used in config conditional matching so that conditions are applied consistently. This path is then tested against the filesystem and the longest existing path is used as the request target, with the remainder of the path treated as PATH_INFO. Since lighttpd has no way in advance to know what is part of the PATH_INFO, the entire path is normalized. (The patch you suggested above is not recommended since it might allow a malicious URL crafted with %2F earlier in the URL path to potentially cause config conditional match to fail to match a condition when it should match that condition (false-negative).)

If you have special needs to preserve the distinction between '/' and '%2F' in the request, then you can obtain that from the REQUEST_URI, which is still url-encoded. It is recommended that you put a tag at the beginning of the path_info in the URL to make it easy to find, e.g. http://example.com/physical/path/to/file/mytag/rest/of/path_info, and then you can url-decode the path following "mytag", skipping '%2F' if you wish.