Apache returning 404 if pathinfo includes partially URI-encoded URL

Question

(Wow, that title sucks... Feel free to make a suggestion in comments or edit it if you have a better one.)

I have a server with a CGI program which receives a URL as pathinfo, checks the user's IP address, and redirects them to either go directly to that URL (if they're internal to our organization) or send them to the URL via a proxy (if they're external). The CGI itself works great, but there are some URLs for which apache returns a 404 Not Found error instead of invoking the script. It appears that this is related to the destination URL containing a URI-encoded path. e.g.,

http://myserver.org/cgi-bin/ipchk/http://other.server.org/10.1007%2F3-540-28519-9_8

returns 404, while

http://myserver.org/cgi-bin/ipchk/http://other.server.org/10.1007/3-540-28519-9_8

(the same URL, but with the %2F decoded to a /) works properly.

I have verified (by outputting to error_log on startup) that, when 404 is returned, the ipchk script is not being started at all. These errors are definitely coming from apache itself and not resulting from the script redirecting users to a nonexistent URL.

Why would the encoding of the pathinfo-URL affect apache's ability to locate the ipchk script and what do I need to do to get it to pass all /cgi-bin/ipchk/ URIs to ipchk regardless of what may follow?

Answer 1

As part of an attempt to protect users from CGI code which doesn't properly decode data before checking incoming paths, apache rejects (as 404 Not found) URLs containing the URI-encoded forms of forward slashes (%2F) or backslashes (%5C), as explained in this article.

To bypass this check, you must be using apache 2.0.46 or later and enable the AllowEncodedSlashes directive in the apache configuration. (This directive does not work from .htaccess; it is only allowed in the server or virtual host contexts.)