Hi!
Function send-output in modlisp.lisp handles the response for different return codes. E. g. there's a "The requested URL ~A was not found on this server." for the 404 (+http-not-found+).
How about letting the user change this behavior?
One could explain the error to the user. Maybe in another language.
Or think of all the funny 404 games. Remember the SGI babies?
There could be different approaches:
* Simple hash A hash with error code as key and handler as value.
+ Easy to implement + Can handle all errors (thrown by handlers _and_ when no dispatcher is found) - Not very flexible. Just checks for the code and not for any request data.
* Error dispatcher Like the normal dispatcher, but checking for the right error output handler.
+ Can handle all errors (thrown by handlers _and_ when no dispatcher is found) + Flexible. Can check the code _and_ request data. - A bit big. The same effort like handling normal requests.
* Handler outputs itself and signals that A handler wants to return a 404. It constructs the output string and signals the fact that there's no need for TBNL to build the HTML for the output.
+ Easy to implement(? clean?) + Flexible - Can't handle all errors. (No handler found? Then the code won't be executed.)
Regards, Stefan
On Sat, 31 Jul 2004 02:10:11 +0200, Stefan Scholl stesch@no-spoon.de wrote:
Function send-output in modlisp.lisp handles the response for different return codes. E. g. there's a "The requested URL ~A was not found on this server." for the 404 (+http-not-found+).
How about letting the user change this behavior?
One could explain the error to the user. Maybe in another language.
Or think of all the funny 404 games. Remember the SGI babies?
Like so? http://weitz.de/not-there
:)
There could be different approaches:
Simple hash A hash with error code as key and handler as value.
- Easy to implement
- Can handle all errors (thrown by handlers _and_ when no dispatcher is found)
- Not very flexible. Just checks for the code and not for any request data.
Error dispatcher Like the normal dispatcher, but checking for the right error output handler.
- Can handle all errors (thrown by handlers _and_ when no dispatcher is found)
- Flexible. Can check the code _and_ request data.
- A bit big. The same effort like handling normal requests.
Handler outputs itself and signals that A handler wants to return a 404. It constructs the output string and signals the fact that there's no need for TBNL to build the HTML for the output.
- Easy to implement(? clean?)
- Flexible
- Can't handle all errors. (No handler found? Then the code won't be executed.)
I agree that this would generally be a good idea. I'm not sure yet which of the above-mentioned alternatives I like most or if there's another one that would even be better.
Cheers, Edi.
On 2004-08-03 07:34:48, Edi Weitz wrote:
On Sat, 31 Jul 2004 02:10:11 +0200, Stefan Scholl stesch@no-spoon.de wrote:
There could be different approaches:
Simple hash A hash with error code as key and handler as value.
- Easy to implement
- Can handle all errors (thrown by handlers _and_ when no dispatcher is found)
- Not very flexible. Just checks for the code and not for any request data.
Error dispatcher Like the normal dispatcher, but checking for the right error output handler.
- Can handle all errors (thrown by handlers _and_ when no dispatcher is found)
- Flexible. Can check the code _and_ request data.
- A bit big. The same effort like handling normal requests.
Handler outputs itself and signals that A handler wants to return a 404. It constructs the output string and signals the fact that there's no need for TBNL to build the HTML for the output.
- Easy to implement(? clean?)
- Flexible
- Can't handle all errors. (No handler found? Then the code won't be executed.)
* Generic function Make a specialized method if you want to catch a certain error. E. g. (defmethod error-handler ((code (eql #.+http-not-found+)) ...
+ Easy to implement + Can handle all errors (thrown by handlers _and_ when no dispatcher is found) + Let CLOS to the "lookup" work + CLOS: You can add :before, :around, :after, ... methods - Not very flexible. Just checks for the code and not for any request data.
I agree that this would generally be a good idea. I'm not sure yet which of the above-mentioned alternatives I like most or if there's another one that would even be better.
Do we need all the features (and more) of Apache's ErrorDocument? http://httpd.apache.org/docs/mod/core.html#errordocument
A function can call the redirect itself.
If you don't need someting similar to the contexts (server config, virtual host, directory, .htaccess) of ErrorDocument then a hash table or generic function is enough.
The contexts can be simulated with error dispatcher which checks the request, too.
But how often would someone need this together with mod_lisp? If someone wants to emit different error messages for the same error code but different request data (host, uri, ...) then he could handle this himself.
Regards, Stefan
Hi!
On 2004-07-31 02:10:11, Stefan Scholl wrote:
Function send-output in modlisp.lisp handles the response for different return codes. E. g. there's a "The requested URL ~A was not found on this server." for the 404 (+http-not-found+).
How about letting the user change this behavior?
One could explain the error to the user. Maybe in another language.
Or think of all the funny 404 games. Remember the SGI babies?
I've implemented a very easy solution for this:
[Special variable] *http-error-handler*
This variable holds NIL or a function designator. The function gets called with an error code other than +http-ok+ or +http-not-modified+ and can return the content of an error page. Return NIL if the submitted error can't be handled. (Note that the handler function can access the request and reply data.)
Now my own error handler can see if it has something to say. Checking error code and maybe some further data from the request. Very KISS.
Patch attached.
Regards, Stefan
-
Edi Weitz -
Stefan Scholl