Redirect for error pages
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
This is what I suspect. IE is waiting a little bit (too little) and then, just shows their page if the bits arent' there. That's why I say ... it seems to be a race. Sometimes the custom page wins (the bits get there before IE decided to show the 'friendly page') or ... most of the time ... the bits dont' get there fast enuff & IE says ... 'show the friendly page then'.IE either waits a little bit for the necessary bits to come streaming out, or IE goes ahead and shows their page
Just an empirical guess.
I've requested the Apache config file from my host, but it will be a while before I get a response. Do you want me to post it here, when I do or can I contact you and send it to you?
---
Feyd ... I tried the 100% mod_rewrite, but ended up with a server error. I changed the 2 path statements to my fully-qualified path to the 404.php error file.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Okay. Let's try this, although it may seriously mess up browser output... you never know.
Code: Select all
header('Content-Length: 1000');I've inserted that, assuming that it goes before anything else, in the 404.php file that's called in .htaccess ErrorDocument, as such:
With the following effect: No errors, but only the "friendly 404 message"
Location of the custom 404.php error file
EDIT - Getting the Apache config file is going to be longer than I was hoping:
Code: Select all
<?php header('Content-Length:1000'); ?>
<!DOCTYPE html PUBLIC "e;-//W3C//DTD XHTML 1.0 Strict//EN"e; "e;http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"e;>
<html xmlns="e;http://www.w3.org/1999/xhtml"e; xml:lang="e;en"e;>Location of the custom 404.php error file
EDIT - Getting the Apache config file is going to be longer than I was hoping:
We have to get a permission from the system administrators.
I will forward this ticket to our system administrators.
Best Regards, Dave
siteground.com
Last edited by stk on Tue Mar 15, 2005 6:34 pm, edited 1 time in total.
I already mentioned that your 404 page should be more than 512 bytes in order to work with or without the IE settings. That is exactly what i did, and now my customer page shows up correctly on IE and others.stk wrote:feyd ...
I can try utilizing mod_rewrite solely, but I have a sneaking suspicion that because the way mod_rewrite works, the result will be the same.
But what the heck?!![]()
Ambush ...
It's always heartening to know that someone else can verify your problem. Somehow, it makes one feel LESS insane!![]()
I will ask the host support for a copy of the httpd.conf file.
RE the 'content-length header'. I'm sorry, I have no clue what you're talking about (I guess it just went over my head when Feyd asked me the same question earlier). How do I find out what 'content lengths' are being sent now? What php code would need be added to correct/modify these 'content lengths'?
Hongco ...
My host already suggested the IE setting, but this is far from the solution that I'm looking for. If I see other's 404 custom pages with 'show friendly' turned ON or OFF ... that's exactly the same behavior I'm looking for with my pages.
-Scott
try my site to see what i was trying to say:
http://www.honqueviet.com/nopagefound.php
Last edited by hongco on Tue Mar 15, 2005 6:35 pm, edited 1 time in total.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Hongco,
My 404.php file is 2.21KB, well above the MSIE 5.5+ minimum of 512 bytes. I am aware of the 512-byte minimum, as I posted earlier. (To repeat, I have inserted some rather derrogatory comments, aimed at IE and Bill Gates, that I found on the Internet, while investigating this issue, early on, that specifically bump up the file size so that is no longer the issue).
Unfortunately, THAT isn't my issue.
But thank you for the suggestion.
My 404.php file is 2.21KB, well above the MSIE 5.5+ minimum of 512 bytes. I am aware of the 512-byte minimum, as I posted earlier. (To repeat, I have inserted some rather derrogatory comments, aimed at IE and Bill Gates, that I found on the Internet, while investigating this issue, early on, that specifically bump up the file size so that is no longer the issue).
Unfortunately, THAT isn't my issue.
But thank you for the suggestion.
Sorry Ambush. I'm not understanding. I already have a 'redirecting' solution.
I thought we were trying to figure out a way to utilize the straightforward "ErrorDocument" .htaccess solution, which would call a plain (non-redirecting) 404.php file.
(My redirect solution is in another file and it WORKS fine).
But it still doesn't explain WHAT the HECK is happening.
I thought we were trying to figure out a way to utilize the straightforward "ErrorDocument" .htaccess solution, which would call a plain (non-redirecting) 404.php file.
(My redirect solution is in another file and it WORKS fine).
But it still doesn't explain WHAT the HECK is happening.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
...
The redirect solution works fine... hmm... the plot thickens. It is time to review what we have discussed before, and see If we missed anything obvious.
Intruiging. Intruiging. This seems to be the thing that works sometimes and other times no.
WTF?
Wait... is this the code that doesn't work, or does work? And what's the code that does work? The plot thickens... basically, I'm not so sure what you're doing with the redirect that makes it work. Could you elaborate?
The redirect solution works fine... hmm... the plot thickens. It is time to review what we have discussed before, and see If we missed anything obvious.
Code: Select all
ErrorDocument 404 /_errors/404.phpWTF?
Wait... is this the code that doesn't work, or does work? And what's the code that does work? The plot thickens... basically, I'm not so sure what you're doing with the redirect that makes it work. Could you elaborate?
It is a knotty problem and very un-computer like, which makes it a very interesting problem, no doubt.
So let me explain what (I think) we know so far and maybe they'll be some light shed into the dark corners.
1) A straight 404 ErrorDocument statement in the .htaccess file yields sporadic results in MSIE. 80% of the time - "friendly message", 20% (or so) "custom 404.php" file.
2) At first, my host provider claimed that it was the php code, but I made my 404 error file a plain-old HTML file (>512 bytes, as per the MSIE min requirement snafu). When I did, the success RATE improved, but was STILL not 100% successful.
3) My host tried eliminating the error FILE altogether, by using error TEXT in the .htaccess file (with the same MSIE-failure results).
4) My host said, "Yeah, there's a problem, but we've not seen it before and we can't do anything for you. G'night, you're on your own."
5) A friend suggested using php to redirect MSIE traffic to another file and I tried it. (My first posts at this forum were elucidation regarding the php "header" function). But I also wanted to pass environmental variables along to the redirected session [My next posts involved learning about session_start()]. And then today, when I first posted, I was redirecting fine ONLY ON THE FIRST 404 error for a window. Type in another wrong file and I received the oft-noob error "Warning, cannot modify header info ... blah blah blah". So today, I learned about buffering [ob_start() and ob_end_flush()], which has seemingly taken care of the problem. So .. that is my solution.
a) .htaccess points to a file (call it 404.php, for grins)
b) that file gathers env info & redirects to the another (call it 404new.php), which is the REAL custom error file.
c) That 404new file collects the session variables, starts the buffer, does the script that emails me some info, pushes the 404 error message and flushes the buffer. Bing batta bam.
You can test the working version on our subdomain: http://pct-hike.randsco.com/no-such-file.html
So far, my tests show 100% success in MSIE.
.htaccess contains only:
the 404.php file contains the following php code, placed at the tippy top
The redirected file contains several things, most notably, the following php at the tippy topa couple of php include statements, some other php code to format the env variables and email the information, HTML and ends with immediately prior to the closing body tag.
NOTE: This solution only exists on our subdomain. Our MAIN domain is simply calling the 404.php file from within the root-level .htaccess file.
6) On our MAIN domain, I have tried using a mod_rewrite to replace the 404.php file that ErrorDocument calls, with 404new.html ... but, this yields a similar result to just using ErrorDocument without the mod_rewrite (not 100% success). No errors ... just not 100% success.
7) Feyd suggested doing away with the ErrorDocument statement and trying a 100% mod_rewrite solution. I used his posted code, inserting the fully-qualified location of my 404.php file, but received a server error code and have not pursued this further, figuring that the result would be similar to (6) and not having the immediate knowledge to track down the syntactical error.
So that's where we sit.
I suspect that there is something wonky with the SiteGround.com server setup, but because they are unresponsive to my inquiry, I have know way of eliciting their assistance.
Anyway ... I thank you for yours, fruitful or not, this remains (a) an intriguing problem and (b) a thorn in my side!
-Scott
So let me explain what (I think) we know so far and maybe they'll be some light shed into the dark corners.
1) A straight 404 ErrorDocument statement in the .htaccess file yields sporadic results in MSIE. 80% of the time - "friendly message", 20% (or so) "custom 404.php" file.
2) At first, my host provider claimed that it was the php code, but I made my 404 error file a plain-old HTML file (>512 bytes, as per the MSIE min requirement snafu). When I did, the success RATE improved, but was STILL not 100% successful.
3) My host tried eliminating the error FILE altogether, by using error TEXT in the .htaccess file (with the same MSIE-failure results).
4) My host said, "Yeah, there's a problem, but we've not seen it before and we can't do anything for you. G'night, you're on your own."
5) A friend suggested using php to redirect MSIE traffic to another file and I tried it. (My first posts at this forum were elucidation regarding the php "header" function). But I also wanted to pass environmental variables along to the redirected session [My next posts involved learning about session_start()]. And then today, when I first posted, I was redirecting fine ONLY ON THE FIRST 404 error for a window. Type in another wrong file and I received the oft-noob error "Warning, cannot modify header info ... blah blah blah". So today, I learned about buffering [ob_start() and ob_end_flush()], which has seemingly taken care of the problem. So .. that is my solution.
a) .htaccess points to a file (call it 404.php, for grins)
b) that file gathers env info & redirects to the another (call it 404new.php), which is the REAL custom error file.
c) That 404new file collects the session variables, starts the buffer, does the script that emails me some info, pushes the 404 error message and flushes the buffer. Bing batta bam.
You can test the working version on our subdomain: http://pct-hike.randsco.com/no-such-file.html
So far, my tests show 100% success in MSIE.
.htaccess contains only:
Code: Select all
ErrorDocument 404 /_errors/404.phpCode: Select all
<?php
session_start();
$_SESSION['ip'] = getenv("REMOTE_ADDR");
$_SESSION['uri'] = getenv("REQUEST_URI");
$_SESSION['srvr']= getenv("SERVER_NAME");
$_SESSION['refr']= getenv("HTTP_REFFERER");
$_SESSION['agnt']= getenv("HTTP_USER_AGENT");
header("Location: http://mysubdom/_errors/404new.php"); ?>Code: Select all
<?php session_start();
$ipAddress = $_SESSION['ip'];
$request = $_SESSION['uri'];
$server = $_SESSION['srvr'];
$referrer = $_SESSION['refr'];
$browser = $_SESSION['agnt'];
?>
<?php ob_start(); ?>Code: Select all
<?php include("http://randsco.com/randsFooter.ssi") ?>
<?php ob_end_flush(); ?>NOTE: This solution only exists on our subdomain. Our MAIN domain is simply calling the 404.php file from within the root-level .htaccess file.
6) On our MAIN domain, I have tried using a mod_rewrite to replace the 404.php file that ErrorDocument calls, with 404new.html ... but, this yields a similar result to just using ErrorDocument without the mod_rewrite (not 100% success). No errors ... just not 100% success.
7) Feyd suggested doing away with the ErrorDocument statement and trying a 100% mod_rewrite solution. I used his posted code, inserting the fully-qualified location of my 404.php file, but received a server error code and have not pursued this further, figuring that the result would be similar to (6) and not having the immediate knowledge to track down the syntactical error.
So that's where we sit.
Me neither. I am only going on empirical data here. And for me, the larger question is "Why isn't the normal, straight-forward 'ErrorDocument-in-the-.htaccess-file' working properly?"I'm not so sure what you're doing with the redirect that makes it work.
I suspect that there is something wonky with the SiteGround.com server setup, but because they are unresponsive to my inquiry, I have know way of eliciting their assistance.
Anyway ... I thank you for yours, fruitful or not, this remains (a) an intriguing problem and (b) a thorn in my side!
-Scott
Last edited by stk on Tue Mar 15, 2005 9:41 pm, edited 1 time in total.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Wow... nice synopsis. I think that I can give a pretty accurate idea of why your fix works: it stops IE from doing funky things with the 404. It goes like this:
IE: Dumty dumty dum, I'll load missing_file.html!
Webhost: Uh oh... that file doesn't exist. Better give 'em a 404 and an error page.
Sends 404 and begins to send error page
At this point, with your fix, this is what happens
404 is sent, location header is ALSO sent
IE: Oh wow! 404! I want to overload it! Whee!! Oh wait... header's aren't done yet? Ah, a location header! Well, byebye 404 page.
And things work. But if you didn't send the redirect,
IE: Ooh... no more headers. Me sees something strange: They didn't tell me how large the file is! Piffle, that's not right! I think it's 0kb! OVERLOAD AWAY!
And then, if it manages to collect enough bits before overloading, it either goes:
IE: Oh wait... there are enough bytes. Nevermind, I'll load the regular page.
or
IE: Too late. I've already overloaded the page.
Of course, this could all be wild speculation. Has anyone had problems with a PHP 404 page in the past (because most pages are HTML) with IE?
IE: Dumty dumty dum, I'll load missing_file.html!
Webhost: Uh oh... that file doesn't exist. Better give 'em a 404 and an error page.
Sends 404 and begins to send error page
At this point, with your fix, this is what happens
404 is sent, location header is ALSO sent
IE: Oh wow! 404! I want to overload it! Whee!! Oh wait... header's aren't done yet? Ah, a location header! Well, byebye 404 page.
And things work. But if you didn't send the redirect,
IE: Ooh... no more headers. Me sees something strange: They didn't tell me how large the file is! Piffle, that's not right! I think it's 0kb! OVERLOAD AWAY!
And then, if it manages to collect enough bits before overloading, it either goes:
IE: Oh wait... there are enough bytes. Nevermind, I'll load the regular page.
or
IE: Too late. I've already overloaded the page.
Of course, this could all be wild speculation. Has anyone had problems with a PHP 404 page in the past (because most pages are HTML) with IE?
Unfortunately, THIS is my first (and only) experience with custom error pages - TEXT, HTML PHP or otherwise.
My host has not shared whether OTHER clients are experiencing anything similar.
But it seems to matter not. TEXT, HTML or PHP ... MSIE is only sporadically directing the custom error to the screen.
(Remember ... and I forgot to add this to my synopsis, which will take away from it's "niceness" ... is that the PHP code in the 404.php file is being executed 100% of the time. It wasn't until I plugged in that email-to-myself-some-stats that I realized this ... and up till that time, just figured it was pilot-error and I wasn't correctly identifying the PATH to my error file).
So ... MSIE IS executing the php code, but electing to shove it's own 404 friendly message across, instead of the custom one.
I do not know what "overloading" is, but what you describe is very close to the conclusion upon which I've arrived. It's a timing thing. Sometimes the custom message slips in, before MSIE decides to slam the door and say "screw it ... I'm doing my own message."
But the thing that kills me ... I can kinda understand the php taking a longer time ... (gotta be parsed and executed ... in addition to rendering the XHTML, includes and CSS files)
But a plain old HTML file? or worse ... just a text message in the .htaccess file?
Nobody else seems to be reporting sporadic custom message displays in MSIE. Either they WORK or they DON'T.
Methinks that the hosting company has something REALLY odd in its setup, because I can't find anything in my googling of this issue.
My host has not shared whether OTHER clients are experiencing anything similar.
But it seems to matter not. TEXT, HTML or PHP ... MSIE is only sporadically directing the custom error to the screen.
(Remember ... and I forgot to add this to my synopsis, which will take away from it's "niceness" ... is that the PHP code in the 404.php file is being executed 100% of the time. It wasn't until I plugged in that email-to-myself-some-stats that I realized this ... and up till that time, just figured it was pilot-error and I wasn't correctly identifying the PATH to my error file).
So ... MSIE IS executing the php code, but electing to shove it's own 404 friendly message across, instead of the custom one.
I do not know what "overloading" is, but what you describe is very close to the conclusion upon which I've arrived. It's a timing thing. Sometimes the custom message slips in, before MSIE decides to slam the door and say "screw it ... I'm doing my own message."
But the thing that kills me ... I can kinda understand the php taking a longer time ... (gotta be parsed and executed ... in addition to rendering the XHTML, includes and CSS files)
But a plain old HTML file? or worse ... just a text message in the .htaccess file?
Nobody else seems to be reporting sporadic custom message displays in MSIE. Either they WORK or they DON'T.
Methinks that the hosting company has something REALLY odd in its setup, because I can't find anything in my googling of this issue.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
What we can do now is try to emulate it on a different server. I'm going to get to work doing that. If it can't be achieved, it may be something funky with your server's config.
I'm wondering: your workaround currently changes the URL so they don't have the 404 url in their address bar anymore, correct? Could you try changing the Location header to a relative link and see if it still works (when it's like this, Apache handles the redirect internally... but I'm not sure if that would break the fix.)
I'm wondering: your workaround currently changes the URL so they don't have the 404 url in their address bar anymore, correct? Could you try changing the Location header to a relative link and see if it still works (when it's like this, Apache handles the redirect internally... but I'm not sure if that would break the fix.)
The 404 fix is currently in place for our main site http://randsco.com. I've swapped the file names. The ErrorDocument calls "fake404.php" and the redirected file is now "404.php".
The 403 custom page (because it isn't affected) is just a plain ErrorDocument pointing to a 403.php in the same _errors dir.
I don't think that the plain flavor 404.php error ever yielded ANYTHING in the address bar, just as the 403.php error doesn't now. I did notice, however, when I implemented the fix, that the address of the file shows in the address bar (and hence, why, I've swapped the names. Just thought it looked nicer, since the address is now displayed, to have a 404.php show).
Anyway ... yes, the redirect location header points to a fully qualified location. I can, as you suggest, try relative pathing. I'll let you know if the hack continues to work properly with relative paths.
BTW ... my host http://www.siteground.com said
The 403 custom page (because it isn't affected) is just a plain ErrorDocument pointing to a 403.php in the same _errors dir.
I don't think that the plain flavor 404.php error ever yielded ANYTHING in the address bar, just as the 403.php error doesn't now. I did notice, however, when I implemented the fix, that the address of the file shows in the address bar (and hence, why, I've swapped the names. Just thought it looked nicer, since the address is now displayed, to have a 404.php show).
Anyway ... yes, the redirect location header points to a fully qualified location. I can, as you suggest, try relative pathing. I'll let you know if the hack continues to work properly with relative paths.
BTW ... my host http://www.siteground.com said
I have, however, put out a basic phpinfo() file, for you to look at, if you like. http://randsco.com/phpinfo.htmlUnfortunately, sending you the apache 'httpd.conf' is considered a very high risk, and cannot be done, due to our security policy.
Relative paths appear to work without a hitch and I've left it that way.
Code: Select all
<?php
session_start();
$_SESSION['ip'] = getenv("REMOTE_ADDR");
$_SESSION['uri'] = getenv("REQUEST_URI");
$_SESSION['srvr']= getenv("SERVER_NAME");
$_SESSION['refr']= getenv("HTTP_REFERER");
$_SESSION['agnt']= getenv("HTTP_USER_AGENT");
header("Location: _errors/404.php"); ?>