Need to allow encoded slashes on Apache
Asked Answered
C

7

84

I'm currently trying to place a URL within a URL. For example:

http://example.com/url/http%3A%2F%2Fwww.url2.com

I'm aware that I have to encode the URL, which I have done, but now I am getting a 404 error back from the server rather than my app. I think my problem lies with apache and can be fixed with the AllowEncodedSlashes On directive.

I've tried putting the directive at the bottom of the httpd.conf to no effect, and am unsure what to do next. Am I putting it in the right place? If so, does anyone have any other solutions?

Counterpoint answered 8/12, 2010 at 17:32 Comment(1)
In addition to https://mcmap.net/q/240047/-need-to-allow-encoded-slashes-on-apache : If you use RewriteRule instead of ProxyPass you should add NE flag to avoid decoding.Huey
A
69

This issue is not related to Apache Bug 35256. Rather, it is related to Bug 46830. The AllowEncodedSlashes setting is not inherited by virtual hosts, and virtual hosts are used in many default Apache configurations, such as the one in Ubuntu. The workaround is to add the AllowEncodedSlashes setting inside a <VirtualHost> container (/etc/apache2/sites-available/default in Ubuntu).

Bug 35256: %2F will be decoded in PATH_INFO (Documentation to AllowEncodedSlashes says no decoding will be done)

Bug 46830: If AllowEncodedSlashes On is set in the global context, it is not inherited by virtual hosts. You must explicitly set AllowEncodedSlashes On in every <VirtalHost> container.

The documentation for how the different configuration sections are merged says:

Sections inside <VirtualHost> sections are applied after the corresponding sections outside the virtual host definition. This allows virtual hosts to override the main server configuration.

Alius answered 14/12, 2010 at 19:8 Comment(0)
B
124

I kept coming across this post for another issue. Let me just explain real quick.

I had the same style URL and was also trying to proxy it.

Example: Proxy requests from /example/ to another server.

/example/http:%2F%2Fwww.someurl.com/

Issue 1: Apache believes that's an invalid url

Solution: AllowEncodedSlashes On in httpd.conf

Issue 2: Apache decodes the encoded slashes

Solution: AllowEncodedSlashes NoDecode in httpd.conf (Requires Apache 2.3.12+)

Issue 3: mod_proxy attempts to re-encode (double encode) the URL changing %2F to %252F (eg. /example/http:%252F%252Fwww.someurl.com/)

Solution: In httpd.conf use the ProxyPass keyword nocanon to pass the raw URL thru the proxy.

ProxyPass http://anotherserver:8080/example/ nocanon

httpd.conf file:

AllowEncodedSlashes NoDecode

<Location /example/>
  ProxyPass http://anotherserver:8080/example/ nocanon
</Location>

Reference:

Beckibeckie answered 29/3, 2012 at 21:34 Comment(7)
The first two issues were pretty well documented around the net, but issue 3 was a tough nut to crack till I saw this answer. THANK YOU.Minier
Wow. Perfect answer, works, concise. Please make this the accepted answer.Chary
It took me ages to find this answer. Sometimes one upvote is simply not enough. Many thanks!Ladonna
Thanks so much for this; the exact thing that was needed.Clarkin
works a charm when using ProxyPass. Fixed an issue with magento API when using SKU codes containing a slash.Limit
If you are using balancer, you should add nocanon to ProxyPass directive not BalancerMember. Example: ProxyPass /webservice balancer://api/webservice nocanon Thanks to @stenix https://mcmap.net/q/246647/-apache-mod_proxy-url-encodingDaly
My problem was a little different, but nocanon resolved it. I have a GiLab omnibus installation behind a Apache proxy with SSL and some urls (the ones with slashes) failed to go through. Using canonfixed it! So glad I came across this.Scrophulariaceous
A
69

This issue is not related to Apache Bug 35256. Rather, it is related to Bug 46830. The AllowEncodedSlashes setting is not inherited by virtual hosts, and virtual hosts are used in many default Apache configurations, such as the one in Ubuntu. The workaround is to add the AllowEncodedSlashes setting inside a <VirtualHost> container (/etc/apache2/sites-available/default in Ubuntu).

Bug 35256: %2F will be decoded in PATH_INFO (Documentation to AllowEncodedSlashes says no decoding will be done)

Bug 46830: If AllowEncodedSlashes On is set in the global context, it is not inherited by virtual hosts. You must explicitly set AllowEncodedSlashes On in every <VirtalHost> container.

The documentation for how the different configuration sections are merged says:

Sections inside <VirtualHost> sections are applied after the corresponding sections outside the virtual host definition. This allows virtual hosts to override the main server configuration.

Alius answered 14/12, 2010 at 19:8 Comment(0)
S
33

I wasted a great many hours on this problem too. I'm a bit late to the party, but it seems there's a solution now.

As per this thread, there is (was) a bug in Apache such that if you have AllowEncodedSlashes On, it prevents the 404, but it mistakenly decodes the slashes, which is incorrect according to the RFC.

This comment offers a solution, namely to use:

AllowEncodedSlashes NoDecode
Sharpedged answered 17/6, 2011 at 15:5 Comment(0)
A
4

After a fair bit of testing, and looking at the bug in Apache, I've concluded that despite offered solutions in different forums, this is an unresolved issue in Apache. See the bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=35256

The workaround that works for me is to refactor the URI so that the item that can contain the escaped slashes is in the query section of the URI, instead of the path. My tests show that when they are there, they don't get filtered out by Apache, no matter the AllowEncodedSlashes and AcceptPathInfo settings.

So: http://test.com/url?http%3A%2F%2Fwww.url2.com

or: http://test.com/url?theURL=http%3A%2F%2Fwww.url2.com

instead of: http://test.com/url/http%3A%2F%2Fwww.url2.com

This means an architecture change for our project, but it seems unavoidable. Hope you found a solution.

Amadis answered 10/12, 2010 at 22:2 Comment(1)
Hi Rob. Yeah, I got the same result, so had to implement the architecture change too. Little disappointing, but just glad that it works at this stage. Thanks.Counterpoint
A
4

in light of all the hassles, i opted for base64_encoding followed by urlencoding. It works without having to fool around with apache server settings or looking at bug reports. It also works without having to put the url in the query section.

$enc_url = urlencode(base64_encode($uri_string));

and to get it back

$url = base64_decode(urldecode($enc_url));

http://example.com/admin/supplier_show/8/YWRtaW4vc3VwcGxpZXJz

http://example.com/admin/supplier_show/93/YWRtaW4vc3VwcGxpZXJzLzEwMA%3D%3D

Absolution answered 16/2, 2012 at 9:8 Comment(4)
I don't like it, but ended up going this way tooDreher
You will get the same problem here, because '/' is a base64 character.Decoy
A urlencoded / regardless of the method to make it is still a %2F is it not?Kerstinkerwin
The top comment on the php.net website for base64_encode() has a good solution for a URL-safe version: php.net/manual/en/function.base64-encode.php#103849 Basically it involves replacing + and / with alternative chars on encode/decode.Subside
S
3

Replace %2F with %252F at the client side.

This is the double-encoded form of the forward slash.

So when it reaches the server and gets prematurely decoded it will decode it to %2F which is exactly what you want.

Sabbath answered 8/12, 2015 at 9:34 Comment(2)
You should never every double encode: tools.ietf.org/html/rfc3986#section-2.4Carlile
@Carlile But you can double-decode it if you know it has been double-encoded. So you could double-encode that entire component, and then do a second decode on that component on the other side?Directly
A
0

I'm getting the same problem with "AllowEncodedSlashes On", and have tried placing the directive in a couple different places: apache2.conf, httpd.conf, and inside a section, as per an example at http://www.jampmark.com/web-scripting/5-solutions-to-url-encoded-slashes-problem-in-apache.html.

If you haven't already, you might want to set your logging level to debug (another directive) and see if you get the error:

found %2f (encoded '/') in URI (decoded='/url/http://www.url2.com'), returning 404

other not found errors don't provide this info in the logs. Just another diagnostic...

Good luck (to both of us)!

Amadis answered 9/12, 2010 at 22:46 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.