Forum

I wonder if it would be possible to have customisable error pages. We have the options for handing errors off to CGI or specify alternate URLs per error code, but there's no simple option for changing the style of all pages. Hiawatha already allows for custom file directories via XSLT, so I was wondering if the same couldn't be done for the error pages as well.
That said: Cheers and keep up the good work.

Hiawatha version: 9.3.1
Operating System: Linux

Is the 'ErrorHandler' option not what you are looking for?

No, I know about that. I was thinking of changing the template of the error pages without resorting to CGI or essentially duplicating the error page several times and changing just the error description and number. I was thinking of an extension to the ErrorHandler option to allow for an XSLT file.

Basically I was wondering this could be done as for the directory listing. You know, passing error number, descriptive string and request URL (plus date and time possible) as an XML and leaving the actual page to the XSLT file.

This wouldn't require any CGI and allow to change the look of all error pages just by changing one file. XSLT support is already in the server and CGI is a bit unwieldy when anything else is static. And static replacements as ErrorHandler can't have Request URL and the like in the page.

Also, this might be a way to customise error pages for the status codes ErrorHandler does not apply to. Without changing the source code, that is.

I'll think about it, but not for the coming release. In my opinion, the current error codes ErrorHandler can handle should be sufficient. For what error codes do you want the layout to be changed?

All, at once.
It's not really a priority, but toying with the directory listings I realise that it would be nice to be able to change the template. I customised the error pages before, but having to have a handful of pages that are essentially the same was sort of inelegant. Plus there are situations when the server generates errors that are not allowed for error handler. 500 comes to mind for one thing. CGIs might generate others which may be up for to hiawatha to handle when using TriggerOnCGIStatus. Which, of course, is helpful when mixing dynamic and static pages.

As is, there's simply no way to consistently change all the error pages. Plus using XSLT is simply elegant and consistent with the other server generated pages (i.e. directory listings).

As I said, it's nothing terribly pressing. But it would be a nice feature to have, so you might want to look into it when you find the time. No reason to make a great webserver even better... except you having reason not to or lack the time, of course.

The 500 error is generated when something goes wrong inside the webserver. Could be memory allocation, disk access, network error (FastCGI process) or some other system error. The only sane option is to abort the process as soon as possible. Starting an XSLT process in such situation is not wise if you ask me.

For all the other errors, I'll think about it. But no promises yet.

What I have now is a per-host option to specify an XSTL file. This one will be used with the following XML generated by Hiawatha:

<?xml version="1.0" encoding="ISO-8859-1"?>
<error>
	<code>404</code>
	<message>Not Found</message>
	<hostname>www.example.com</hostname>
	<request_method>GET</request_method>
	<request_uri>/file.txt</request_uri>
	<software>Hiawatha v9.0</software>
</error>

The hardcoded error message will be shipped with the source package. Ok for you?

I'm not quite sure what you mean with the hardcoded error message being shipped with the source package, but allowing for a per host XSLT file sounds perfect. Will it also be possible to set one for all virtual hosts (server default)? Just asking.

I mean that I have converted the error message Hiawatha shows now, which is hardcoded, to XSLT and it will be shipped with the next Hiawatha release.

Perfect, thanks.

Just let me add that Hiawatha is really a great piece of software and much appreciated. You may not be able to take on Apache in the number of big site installations, but only because of inertia and less publicity. But make no mistake: People are using it. Thanks for creating it.