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
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.
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)!
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
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.
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.
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: