AllowEncodedSlashes default change in Apache 2.4.58: impact on mod_proxy encoded‑slash forwarding

The goal is to understand how Apache 2.4.58’s new default for AllowEncodedSlashes (Off) changes the handling of URLs that contain encoded slashes when they are forwarded by mod_proxy to a backend server.

With the directive now context‑sensitive and applied to all virtual hosts unless overridden, an encoded slash (%2F) is rejected unless the server explicitly allows it. When AllowEncodedSlashes is Off, a request that contains an encoded slash is dropped and the client receives a 404 response, but the exact error path and logging behavior are undocumented. It is unclear whether mod_proxy should honor the target backend’s AllowEncodedSlashes setting or use its own default, leading to inconsistent results across deployments.

Key unresolved questions are:

• When AllowEncodedSlashes is Off, does mod_proxy forward a request containing an encoded slash if the backend allows it?
• What specific log entry, if any, is produced when the request is dropped due to an encoded slash?
• Is there a documented or recommended configuration pattern to achieve predictable behavior for reverse‑proxy scenarios involving encoded slashes?