Bug #1482
lighty does not appear to use server.errorfile-prefix when fastcgi returns error
| Status: | Invalid | Start: | ||
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | core | |||
| Target version: | 1.4.20 | |||
| Pending: | No |
Resolution: | invalid |
|
| Patch available: |
Description
using lighttpd-1.4.18 FreeBSD 6.1, php-fcgi 5.2.5
when php has a fatal error (with display_errors=Off) the famous "white page" is returned.
php appears to return an http status code = 500. (confirmed under apache2 mod_php and lighttpd fastcgi).
I was hoping that lightly would map this return code to the page pointed to by
server.errorfile-prefix
My setup worked for a straight 404 (where lighty had the "error" rather than php) and the custom 404 page was displayed, but the same did not happen when php returned the 500?
Would be possible for lighty to use custom error pages according to fastcgi error codes?
History
12/17/2007 03:22 PM - oschonrock
after looking into this further, this is not a reasonable request. lighty just passes whatever the fastcgi process generates to the browser client.
it would be unreasonable for lighty to parse the http response generated by the fastcgi backend and then map certain response codes to custom error documents.
please close as bogus (i don seem to be able to do that myself).