Programmable error pages on Apache: can I use SSI or s.t. else?

My knowledge is a bit rusty and my previous configuration got lost during a mistake in a migration process. A few questions to appear in a series to get it back again. Nr 6:

In addition to the previous question http:Q_24356129.html  I would like these error pages to be slightly  programmable, but I know that it is not a smart idea to use some cgi or scripting (php/perl whatever) for it, since an error might be caused by the absence or inaccessibility of either of them. Would something like SSI do (all I need to know is customize a bit based on some environment variables and the current host) or are there other reasonable alternatives that have a small chance to fail?

I understand I should never use this on HTTP 500 errors, for obvious reasons. In case an error page has an error itself, what will the apache server do and what will the user see?
LVL 39
abelAsked:
Who is Participating?
 
caterham_wwwConnect With a Mentor Commented:
> In case an error page has an error itself, what will the apache server do and what will the user see?

If the error page produces an error, the build-in message will be returned (with an additional info that there was an error with the ErrorDocument, too). But that is not the same with SSI; in that case just the SSI part failed and not your error page. You'll see sthg. like [an error occurred while processing this directive] in your HTML source code of your custom error document output instead of the expected result of your SSI command.

> I understand I should never use this on HTTP 500 errors

There are also some situations where the processing is aborted immediately so that the ErrorDocument is not processed at all (HTTP 400 bad request could be such an example).
0
 
abelAuthor Commented:
Good point, that last one. I'd probably go for the access denied and page not found errors anyway. And considering your explanation on SSI above, it shouldn't be too much of a problem to use this with 500-errors.

Anyway, I'm merely gathering information just to know I'm on the correct track. I'll try it out and get back to you.
0
 
caterham_wwwCommented:
> it shouldn't be too much of a problem to use this with 500-errors.

No. If there's a severe problem the page wouldn't be displayed at all (e.g. if the server is mis-configurated and can't continue the processing).
0
[Webinar] Improve your customer journey

A positive customer journey is important in attracting and retaining business. To improve this experience, you can use Google Maps APIs to increase checkout conversions, boost user engagement, and optimize order fulfillment. Learn how in this webinar presented by Dito.

 
caterham_wwwCommented:
(no=no, no problem to use a 500 error doc)
0
 
caterham_wwwCommented:
What you should never do is to use ErrorDocs for status codes <400. If you use some for the redirect codes (30x) the automatic redirect might stop working.
0
 
abelAuthor Commented:
Yes, I know, no worries there. I'm quite keen on the HTTP protocol, just a bit rusty on the Apache side. But it's coming back... ;-)
0
 
abelAuthor Commented:
all works fine now. Thanks!
0
 
abelAuthor Commented:
tx!
0
All Courses

From novice to tech pro — start learning today.