Jump to content

Recommended Posts

Hi,

 

I got an .htaccess file in the root directory of my webserver with those lines in it:

 

ErrorDocument 404 http://xxxxxx/404.php

ErrorDocument 500 http://xxxxxx/500.php

 

The 404 error displays fine but the error 500 is not working at all, displaying the default error page.

 

Any ideas?

 

Thanks.

Check server logs on the remote server

Check access permissions on the remote server - (might only be the apache process which has direct access to the file)

Check aliases together with permissions on the remote server

 

Check you can access the remote error file directly in a browser from a local machine

 

How are you generating the error 500 locally to test it?

 

If unsure - You can create any dummy text file containing gibberish such as "blah" on the first line as say test500.cgi locally in your /cgi-bin/ folder.

 

Out of curiousity I just tried redirecting from local copy of apache to my own webserver and it works fine using that method of both error reference and error triggering. I can also access the error document directly via http.

 

Hi,

 

The page is generated through an error code in php (parsing error) I was intentionally omitting a ";" to get an error page 500.

 

I can access it directly form the local computer fine.

 

I tried to create the dummy file with "blah" but when I launched the page it was displaying "blah" actually, this might not be a good way to test it...

 

Any ideas?

 

Thanks.

Hi,

 

Here is what I get:

 

Access log:

 

192.168.1.1 - - [16/Jan/2008:01:45:35 -0500] "GET /files.php HTTP/1.1" 500 -

192.168.1.1 - - [16/Jan/2008:01:45:35 -0500] "GET /favicon.ico HTTP/1.1" 302 215

 

Error log:

 

[Wed Jan 16 01:45:35 2008] [error] [client 192.168.1.1] PHP Parse error:  syntax error, unexpected T_VARIABLE in X:\\XXXX\\files.php on line 55, referer: http://XXXX/home.php

[Wed Jan 16 01:45:35 2008] [error] [client 192.168.1.1] File does not exist: X:/XXXX/favicon.ico, referer: http://XXXX/files.php

 

Thanks.

Okay... surely those are the "trigger" logs from where you're triggering the simulated 500 error?

 

Just to double check my assumptions here. You've specified a REMOTE 500 error page by prefixing with http://xxxxx... rather than using  path /error/errorxxx.php. Might be talking at cross purposes and there may be no remote box hosting the error page - but lets assume so at the moment (otherwise there'e be no point in using a full http:// URL in the .htaccess)....

 

So - Your remote server help page is what isn't working as far as I recall.

 

Sure you're geting a 500 error page "hit" on the configured REMOTE server with the 500 error page???

 

If you aren't getting linked 500 error page retrieval hits on the remote box with the help page then I guess it might be some obscure bug or interaction between using .htaccess and/or using PHP faults to trigger the 500 error.

 

You could work through it I guess by redirecting the error page back to the test box using a local path /error/whatever

get that working using the same PHP script or any other 500 trigger script so you can confirm Apache really IS raising a 500 error, then alter your config and transfer the page call back over to the remote box.

 

Alternately there may well be a complete misunderstanding and it may simply be the fact that you only have one server but for unknown reasons have put in a full http url rather than a local path (just clutching at straws) ;)

Hi,

 

"Sure you're geting a 500 error page "hit" on the configured REMOTE server with the 500 error page???"

 

How can I verify this?

 

"If you aren't getting linked 500 error page retrieval hits on the remote box with the help page then I guess it might be some obscure bug or interaction between using .htaccess and/or using PHP faults to trigger the 500 error.

 

You could work through it I guess by redirecting the error page back to the test box using a local path /error/whatever

get that working using the same PHP script or any other 500 trigger script so you can confirm Apache really IS raising a 500 error, then alter your config and transfer the page call back over to the remote box.

 

Alternately there may well be a complete misunderstanding and it may simply be the fact that you only have one server but for unknown reasons have put in a full http url rather than a local path (just clutching at straws)"

 

Could you provide me the steps to achieve that so I can try?

 

Thanks!

Run some tests then just watch the logs in real time using tail -f logfilename on each server involved

 

tail is usually included with Linux distros

 

I'm still not 100% sure about your config. You really ARE redirecting error page requests to another box aren't you??

 

Hi,

 

Here is my configuration, should have precised that before though I am sorry...

 

Windows computer with Apache 2.2.6 (Win32) and PHP 5.2.5

 

The error page is on the same server, I tried to get rid of the http://... part of the .htaccess document, it is now: ErrorDocument 500 /500.php

 

It works fine with ErrorDocument 400 /400.php or ErrorDocument 403 /403.php but still not with the ErrorDocument 500 /500.php

 

Any ideas?

 

Thanks.

Ah! Windows

 

OK - usual comments (i.e. check for typos)

 

If you have names with spaces in them, have you wrapped the names in double quotes?

Also ensure you use FORWARD slashes in all config files for paths - / not \

Ensure you have a root alias for /error/ and prefix this root path to your error filenames

It is far perferable to use the main server config rather than .htaccess

If error documents are global to the server I'd recommend only ever defining in the main server config file

or you might run into a conflict between the main server config and an override

 

Perhaps?

 

ErrorDocument /error/400.php

ErrorDocument /error/500.php

 

I have written free versions of tail for Win32 if you need copies (CGI, CMD line, and Windows app)

Note also that you might try temporarily increasing log verbosity to "Debug" and then watching logs in real-time

I can't manage without my copies of tail!! :)

 

Hi,

 

The error pages are on the root of a virtual host, this is why I have to specify it in a .htaccess.

 

I did try though to place the commands on thmain server configuration file (httpd.conf) and the problem was the same, the 404.php page is working if I type a wrong URL but not the 500.php if I force a parse error and then try to loasd the page, it loads the default windows page 500 instead.

 

Any ideas from here?

 

Thanks.

Both ErrorDocument and Alias are within context for Virtual Host.

Still not sure why this "has" to be done in .htaccess

Have you tried doing it in the vhost config section and had it fail??

i.e. override main config default with vhost error alias/document config

 

http://httpd.apache.org/docs/2.0/mod/core.html#errordocument

http://httpd.apache.org/docs/2.0/mod/mod_alias.html#alias

 

The page you're getting isn't the "default windows page 500" it is almost certainly the default Apache error from context of the main config file. My guess is your .htaccess isn't properly overriding.

 

I really would recommend trying this using the simplest and most reliable method of putting it in the main server config (vhost config section if need be).

 

You may need to mark each differing (main config v's vhost) 404 page etc. so you can track exactly which one is being called.

 

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.