I’m sorry, but what is exactly supposed to be shown on the index page? You’ve disabled directory indexes in every way possible, and you’re rewriting requests to .php URLs, but if a particular URL is not matched to a file and isn’t caught by the rewrite rules, what should happen?
The URL comes in, is put into a GET var & is passed to ITPage, which then parses the URL – generating its own 404 if need be – , determines what DB info should be grabbed, builds the page on the fly then sends it to the user. It’s versitile, is quick, and has worked well for 10 years…
…only now, it’s dying in htaccess & I haven’t been able to find an error log to tell me why…
I’ve checked your .htaccess rules, and the RewriteRule only matches URLs with the .php extension. This means the base URL of your website is not matched by this rule.
Maybe it would work if you wrote your .htaccess rules like this:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ http://intourlydev.gq/ITPage.php?IT=$1?%{QUERY_STRING}&DOM=%{HTTP_HOST}&IP=%{Remote_Addr} [P,L]
Nope, still getting the 404 (an infinityFree 404, btw). I’ve tried to delete and/or rename the top-level htaccess and it won’t let me…any way you could disable it & see if that’s a fix?
If you suspect it’s breaking something, you can just delete the default .htaccess file. It’s not possible to edit or recreate it, but you can delete it. But most likely, you’ll just see a different 404 error.
I should have noticed this before, but after some testing, it looks like the problem is caused by the fact that the RewriteRule line ends with [P,L]. The letter P here means that the RewriteRule doesn’t actually do a rewrite, but does a proxy request instead. So it could in theory be used to “rewrite” to a URL on a different domain and hosting service.
But web proxies tend to be prone to abuse, which is why they are prohibited on our hosting, and blocked wherever possible. And I suspect the reason you see a 404 response is because the server doesn’t accept this option.
In order to use traditional URL rewriting, rather than proxying, you’ll probably want to do something like:
Change the [P,L] flags to `[L]’ only.
Use a file path to rewrite to, instead of a full URL.
By comparison, the RewriteRule of WordPress looks like this: RewriteRule . /index.php [L].
This may not work with the additional query parameters you add to the URL, but those values (client IP and domain) can be retrieved from $_SERVER instead.
Weird thing. After a bit, I reloaded the page, and my ITPage came up! But then I reloaded and got a ‘server not found’ error. I reloaded yet again and this time got an InfinityFree 404 page (which, incidentally, I’ve deleted from my local space.
The [P] parameter is required to preserve the original url for display in the address bar – all the redirection is supposed to go on behind the scenes…
I really suspect the top-level htaccess is the culprit here, but it won’t let me delete, rename, move, or edit it. If it’s to go away, it’s gonna have to be something you do…
…but if your host won’t let me do the [P] directive regardless, than I think I should just go find a free host that lets me do that…
I just made a slight change to your .htaccess file. The top level .htaccess file is untouched, all I did was slightly change the rewrite rule so it doesn’t require the [P] flag anymore. This was the solution I proposed to you in my previous message.
If you still insist on using your old config, then I’m afraid that our hosting will not work with you. But what you can see now is that with only a very few number of changes, it works perfectly fine without the [P] flag.
Well, [P] directive was there to retain the original URL…but whatever you did, it seems to be working correctly (or, at least, better), as far as I can tell…
New problem is MySQL dies on connect, throwing an
Failed to connect to MySQL: Access denied for user ‘epiz_xxxxxxxx’@‘xxx.xxx.%’ to database ‘epiz_xxxxxxxx_xxxxxxxx’
I copied the creds directly from the MySQL Databases page in cPanel:
I have checked your config and it looks like the database name is not correct. Please note that database names are case sensitive and are automatically normalized to all lowercase letters. So if there is any capital letter in your database configuration, it will not work.
I checked your website but I don’t see any error like that.
My first guess would be that there is an issue with the URL. Which could mean it’s either returning some bad status code because of a bad .htaccess rule, or just a 404 URL because the file is called differently.
Another option is that the URL may be hard coded to the non-www version of the URL but your website is accessed with the www version. Any sort of cross domain hotlinking is not possible on free hosting, even if it’s on the same domain.
But that’s just a guess, I don’t see the same problem on my end.