When working with Apache's mod_proxy to forward URLs containing encoded forward slashes (%2F), we encounter three distinct behaviors based on AllowEncodedSlashes configuration:

# Case 1: Default configuration (parameter missing)
http://ntung-gitblit.localhost/ABC%2fXYZ → 404 error

# Case 2: AllowEncodedSlashes On
http://ntung-gitblit.localhost/ABC%2fXYZ → http://myserver:1279/ABC/XYZ

# Case 3: AllowEncodedSlashes NoDecode  
http://ntung-gitblit.localhost/ABC%2fXYZ → http://myserver:1279/ABC%252fXYZ

The fundamental issue stems from how Apache processes URLs at different stages:

1. URL parsing and normalization
2. mod_proxy request processing
3. Encoding/decoding during forwarding

To correctly proxy URLs with encoded slashes while preserving the original encoding:

# In your virtual host configuration
<VirtualHost *:80>
    ServerName ntung-gitblit.localhost
    
    ProxyPreserveHost On
    AllowEncodedSlashes NoDecode
    
    # Critical modification using mod_rewrite
    RewriteEngine On
    RewriteRule ^/(.*) http://myserver:1279/$1 [P,NE]
    
    ProxyPassReverse / http://myserver:1279/
</VirtualHost>

1. AllowEncodedSlashes NoDecode: Prevents Apache from decoding %2F to / during initial processing.

2. NE (No Escape) flag in RewriteRule: This is crucial - it prevents mod_rewrite from double-encoding the already encoded characters.

3. ProxyPreserveHost: Maintains the original Host header which might be needed by your backend server.

After implementing this configuration, test with:

curl -v "http://ntung-gitblit.localhost/ABC%2fXYZ"

Verify that:

• The backend server receives exactly /ABC%2fXYZ
• No 404 errors occur
• No double-encoding happens (%252f)

For environments where mod_rewrite isn't available or suitable:

<Location />
    ProxyPass "http://myserver:1279" nocanon
    ProxyPassReverse "http://myserver:1279"
</Location>

The nocanon parameter tells mod_proxy not to canonicalize (normalize) the URL path before forwarding.

1. Security implications: Allowing encoded slashes might expose path traversal vulnerabilities if your application isn't properly secured.

2. Performance impact: The rewrite solution adds minimal overhead, but should be benchmarked in high-traffic environments.

3. Backend compatibility: Ensure your backend server (Gitblit in this case) can properly handle the preserved encoded slashes.

---

When working with Apache's mod_proxy to forward requests containing encoded forward slashes (%2F), you might encounter unexpected behavior. The original URL:

http://ntung-gitblit.localhost/ABC%2fXYZ

gets transformed incorrectly during proxy forwarding, either becoming:

http://myserver:1279/ABC/XYZ

or double-encoded as:

http://myserver:1279/ABC%252fXYZ

Apache's default behavior with AllowEncodedSlashes creates this problem:

• AllowEncodedSlashes Off: Returns 404 errors
• AllowEncodedSlashes On: Decodes %2F to /
• AllowEncodedSlashes NoDecode: Double-encodes the slash

To preserve the original encoded slashes, you need to combine several Apache directives:

<VirtualHost *:80>
    ServerName ntung-gitblit.localhost
    AllowEncodedSlashes NoDecode
    
    ProxyRequests Off
    ProxyPreserveHost On
    ProxyPass / http://myserver:1279/ nocanon
    ProxyPassReverse / http://myserver:1279/
    
    RequestHeader unset Accept-Encoding
</VirtualHost>

The critical components that make this work:

AllowEncodedSlashes NoDecode
ProxyPass / http://myserver:1279/ nocanon

The nocanon flag prevents canonicalization of the URL, while NoDecode handles the encoding properly.

After making these changes, test with curl to verify:

curl -v http://ntung-gitblit.localhost/ABC%2fXYZ

You should see the request properly forwarded to:

http://myserver:1279/ABC%2fXYZ

If you're still encountering issues:

• Check Apache's error logs for detailed debugging information
• Ensure no other modules are interfering with URL processing
• Verify that the backend server can handle encoded slashes

For more complex scenarios, you might consider using mod_rewrite:

RewriteEngine On
RewriteRule ^/(.*) http://myserver:1279/$1 [P,NE]

The NE (noescape) flag prevents rewriting of encoded characters.

Be aware that using nocanon and NoDecode may have minor performance impacts as Apache skips some URL normalization steps. However, for most applications, this overhead is negligible compared to the network latency of the proxy request itself.