See also T13644, which appears to be the origin of the particular requests observed in PHI2021.

This reproduces locally.

In Diffusion, we also encode slashes in the URI (for example, when viewing branch a/b), but double-encode them during responses and single-decode them from requests, with the expectation that the webserver will do one decoding pass. This is why this issue doesn't manifest in Diffusion.

The symbol logic does not do the same thing, but should. This would avoid the problem in all known natural cases (i.e., leaving us with no known case where Phabricator itself legitimately generates a URI containing %2F).

AllowEncodedSlashes On and AllowEncodedSlashes NoDecode are both likely safe, and On is "more correct": it treats these characters like any other characters. However, AllowEncodedSlashes On has some security warnings in the Apache docs. These are almost certainly about applications doing something silly, but who knows.

It doesn't seem worth the effort to do a setup test for this since all the settings are basically moot. The upshot is:

• For any value of this setting, Phabricator's behavior is correct in all known, legitimate cases, where the user is accessing a URI that Phabricator itself generated.
• If a user accesses a URI containing %2f (which Phabricator will never generate), Apache has different behavior depending on the setting. Here's what Apache will pass to Phabricator for the requests /x%2Ey and /x%2Fy. The values it is "supposed" to pass are /x.y and /x/y, respectively:

If you don't like the raw 404 or the log warning, you can set AllowEncodedSlashes NoDecode to silence the log, albeit with technically incorrect (but safe) routing behavior for these URIs. If you don't like technically incorrect behavior and trust that Apache's dire warning about security implications is just about application behavior, you can set AllowEncodedSlashes On.

Previously, see T13437.