EDIT: did more research, asked new question

I dug a bit deeper and realized that the contents of the page are indeed not relevant to this issue. As this question has gotten more and more confusing, I've asked a new question to avoid further muddying the waters.

EDIT: did some more detective work

I've created the following file to display query string parameters and set it up on my webserver:

<!DOCTYPE html> 

<script src="URI.js"></script>
var bodyEl = document.getElementsByTagName("body")[0];
var url = URI(document.documentURI);
var options = URI.parseQuery(url.query());
var optionsDiv = document.createElement("div");
var optionsText = "";
for (o in options) {
  optionsText += "" + o + ": " + options[o] + "\n";
optionsDiv.innerText = optionsText;

It works as expected given the URL http://example.com/querytest/querytest.html?a=1&b=2.

When I send it query string parameters containing a %-escaped url, I get a 403 error from the webserver.

Example URL: http://example.com/querytest/querytest.html?a=1&b=2&source_url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D2Tjp0mRb4XA

However, if I substitute example.com for www.youtube.com in the %-escaped URL, I do not get a 303.

Based on this, I'm guessing that the library I'm using to parse the URL (URI.js) is doing something with the url that violates the same origin policy.

Original post

I'm using shared hosting, i.e. I have no ability to modify the apache installation, root configuration files, etc. I'm developing a web app that passes URLs as query string parameter values. The web server is giving a 403 FORBIDDEN error whenever the query string contains a period character, even if that character is %-escaped — i.e. either "."or"%2E"` in a query string value will trigger the 403.

It seems that the web server thinks that the file extension is everything after the final "." in the query string. How can I get it to act sensibly and realize that it's just part of the query string?

A .htaccess file in the web app's directory is used by Apache. I tried creating one containing the following line, but it didn't do the trick. It's been a while since I worked with Apache config, so I'm not surprised. The second line serves to verify that Apache is actually reading the local .htaccess file.

RewriteRule ^app.html$ app.html [L,NC,NS,QSA]
RewriteRule ^app$ app.html [L,NC,NS,QSA]

Note: originally posted on Stack Overflow but received little attention and no responses.

  • The first rewrite example you gave is redundant. You should remove it. The second is perfectly valid but may not solve your problem. Can you give us examples of the failing URLs (JIC) so that we can be precise in helping you? Thanks!!
    – closetnoc
    Commented Feb 23, 2015 at 19:36
  • Any URL for the page in question with a dot after the ‛?‛ seems to trigger the 403. Hmm actually perhaps I only tried cases where the dot is in the value (rather than the name) of a query string parameter.
    – intuited
    Commented Feb 23, 2015 at 20:24
  • Sorry. I was out for a while. I getcha! But I guess what I was asking, albeit not very well, is what have you tried?? BTW- escape does not work, but encoding might. I am thinking that there has to be something in the configuration or .htaccess that is preventing this from working. I know that you do not have access to the configuration. Can you experiment with a hello world script that will take params outside of your app to see if you get the same behavior? In fact, just an HTML file will do. I use dots in my site params a lot so natively, this should not be an issue.
    – closetnoc
    Commented Feb 23, 2015 at 22:14
  • What makes you think it is related to file extensions? Is there helpful error message shown? Commented Feb 24, 2015 at 0:03
  • I did a bit of experimenting and found that the same behavior occurs for nonexistent files — i.e. a different error code is indicated by the server depending on whether or not there is a dot in the URL even if the URL does not point to a real file.
    – intuited
    Commented Feb 24, 2015 at 0:05

1 Answer 1


Check the actual file you're running the query strings against to see if it is producing the 403 errors. If you create a PHP file that has the following contents and save it and then run it live on the server while using an actual dot in the query string, then you'll get the 403 error.

if (strpos($_SERVER['QUERY_STRING'],".") !== false){
    header("HTTP/1.0 403 Forbidden",true);

Not the answer you're looking for? Browse other questions tagged or ask your own question.