strange htaccess 404 redirect problem

[tintin99]

Hi,

I've spent ages on this problem and can't find a solution anywhere.

In my CMS I get the current page url using $_SERVER["PHP_SELF"] and save it to a session variable. This works fine as long as the page has nothing wrong with it like missing images or stylesheets. If it does then the session variable takes the value "error.php" which is my 404 error page as set by my htaccess file.

I have double-checked and if the page is all correct or if I remove the htaccess file everything works fine.

As this is a CMS I can't guarantee that the pages will never have broken links so I'm stuck.

Any ideas?

[lucy24]

Does the error page have to be set in htaccess? I'm curious about what would happen if you used the custom-name approach instead. A lot of hosts (assuming you are on shared hosting) have a list of default error-document names like "missing.html" that they will automatically look for.

I agree that it shouldn't be talking about the 404 page when the problem is with secondary material. 404 is for pages. Does this always happen, for any and all associated files that might be missing, or is there a pattern?

Nother question. When you say "remove the htaccess file" do you mean the whole file? Or do you just mean remove or comment-out the line that names your ErrorDocument? For that matter, what's the exact wording of the line? Where is it located?

Did you build your htaccess from scratch or are you modifying one that came with the CMS?

[tintin99]

Thanks for your reply! I don't think my host has any default error docs - they suggest using htaccess.

This problem does seem consistent - for example if a page links to an image or a stylesheet that isn't on the server then the error page gets written to the session variable instead of the page url.

The lines in the htaccess file are:

ErrorDocument 401 /error.php
ErrorDocument 403 /error.php
ErrorDocument 404 /error.php
ErrorDocument 500 /error.php

...and yes, I only need to comment out the 404 line to get everything working.

I've written the whole CMS myself from scratch including the htaccess file. The way it works is that the users can browse to a page they want to edit, the page url is written into a session variable and when they go to the editor the page that's in the session variable is shown.

[tintin99]

I've narrowed this down to the bare bones now...

I set up one page with this code:

<?php
session_start();
?>
<br /><img src="aaa.jpg" alt="" height="30" width="90" /><br />
<?php
$_SESSION['page'] = $_SERVER["PHP_SELF"];
echo $_SESSION['page'];
?>

...and another with this:

<?php
session_start();
echo $_SESSION['page'];
?>

The first page references an image which doesn't exist. My htaccess 404 redirect is in place. Running the first page gives the output 'test.php' which is correct, but when I run the second page the output is 'error.php'.

This seems to suggest that the session variable has two values depending on where you view it!

Can someone tell me what I'm doing wrong and put me out of my misery?

Here's hoping...

By the way if I remove the 404 redirect I get the output 'test.php' from both pages.

[g1smd]

You want to be looking at the requested URL as seen from the web, not at the filename that was pulled from the hard drive to satisfy that request.

[lucy24]

Running the first page gives the output 'test.php' which is correct, but when I run the second page the output is 'error.php'.

Does it do this all the time, or only if you run it immediately after the first page? (Implying that it's sending back your starting point, rather than your ending point.)

Does "$_SERVER["PHP_SELF"]" return the public URL or your current physical location? The "SERVER" element makes me uneasy, though technically it may not make any difference if you're only using the information behind the scenes.

Oh, and stop saying "404 redirect" ;) You know what you mean and we know what you mean, but it's still wrong. And what's it doing messing about with 404s for images? It would drive me bonkers. I mean, your page isn't showing a thumbnail of the custom 404 page in the place where the image ought to be.

Just out of curiosity. For testing only; don't keep it for the live site. What happens if you have a different function for nonexistent image files? That is, something involving mod_rewrite, a Rule for (jpe?g|gif) etc, and !-f ? Do you then get the name of your regular 404 document, or the name of the "ain't no such picture" document?

[tintin99]

You want to be looking at the requested URL as seen from the web, not at the filename that was pulled from the hard drive to satisfy that request.

I tried it with $_SERVER['REQUEST_URI'] (is that what you mean?) ...the same thing happened.

Does it do this all the time, or only if you run it immediately after the first page? (Implying that it's sending back your starting point, rather than your ending point.)

I have to run the first page to set the session variable. After that I can run page 2 as often as I like but the output doesn't change. The whole thing is completely consistent and I tried it on a diferent host and got the same result.

Does "$_SERVER["PHP_SELF"]" return the public URL or your current physical location? The "SERVER" element makes me uneasy, though technically it may not make any difference if you're only using the information behind the scenes.

I've tried several of the $_SERVER variables but no difference. For the CMS all I need to do is get the filename of the current page. Is there another way of doing it?

Oh, and stop saying "404 redirect" ;) You know what you mean and we know what you mean, but it's still wrong. And what's it doing messing about with 404s for images? It would drive me bonkers. I mean, your page isn't showing a thumbnail of the custom 404 page in the place where the image ought to be.

What would you like me to call it? :-) Yes, it's been driving me bonkers for some time now!

Just out of curiosity. For testing only; don't keep it for the live site. What happens if you have a different function for nonexistent image files? That is, something involving mod_rewrite, a Rule for (jpe?g|gif) etc, and !-f ? Do you then get the name of your regular 404 document, or the name of the "ain't no such picture" document?

Error pages are about my limit as far as htaccess goes, but if you'd like to suggest a rule I'm happy to give it a go.

Thanks for the help!

[tintin99]

I think I've found the answer: if I pass the current page filename to the CMS using a query string I can set the session variable there and it works fine.

If anyone can explain why my previous method didn't work I'd be interested to know the reason.

Thanks again for your help!

[drazic2012]

I know this thread is a few months old now, but I had the exact same problem today and figured I'd explain how I resolved it.

I was doing something very similar, storing the current URL to a session variable for use on another page, when it suddenly started returning the 404 error page URL instead of the correct page name. If I removed the custom 404 page from my .htaccess file, the script would start working correctly.

Through testing my script, I noticed that if I set my session variable to retain all the values sent to it, it would give me the correct URL, followed by the URLs of any broken images in the page, followed by the 404 page URL.

Then it clicked - my 404 page uses the same template that contains the script to set the session variable. So every time the 404 page loads, it reassigns the session variable. Even when an image can't be loaded in a page, it will silently load the 404 page in the background - changing the value of the session variable.

The easiest way to prevent this is to exclude images and the like from triggering the 404 page in your .htaccess file, like follows:

<FilesMatch "\.(jpe?g|gif|png|bmp|ico)$">
 ErrorDocument 404 "File Not Found"
</FilesMatch>

Other than that, you could also set some conditions where you set your session variable, to try and prevent it from being reassigned depending on the current URL.

[g1smd]

"Unintended consequences" - always difficult to fathom out what is happening, and almost impossible in a forum setting.

Glad you got it fixed.