Honestly it took me a while to debug a vague bug I had, at first I ignored it and used different path values, figuring it was a bad rewrite rule. I'm using a project and I'm developing on both Apache and IIS, with the one inconsistency that I always got a 404 when the path contained a encoded /, namely "%2F". So basically, a URL like this: http://domain.com/show/article/104671-Situation%20details%20n%2Fa (Title being: "Situation details n/a") is giving a 404. The error log was helpful, because it said:
[..] [info] [client 127.0.0.1] found %2f (encoded '/') in URI (decoded='//'), returning 404
Luckily, fixing this bug feature is easy. Add the following to your httpd.conf (vhost or server directive) and voila:
AllowEncodedSlashes On
Arguably you could be saying that %2F's simply shouldn't be in the path, but rather in the POST body or as GET parameter. However in a world where everything has to be SEO and url's have to be pretty, isn't this silly default behavior ? Especially since the RFC's also clearly state that an encoded forward slash (%2F) should not be treated as a regular '/'. To quote RFC 2616
Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
and RFC 2396
2.2. Reserved Characters
Many URI include components consisting of or delimited by, certain
special characters. These characters are called "reserved", since
their usage within the URI component is limited to their reserved
purpose. If the data for a URI component would conflict with the
reserved purpose, then the conflicting data must be escaped before
forming the URI.
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
