[hunchentoot-devel] *http-error-handler* behaviour

[Marijn Haverbeke]

Hi,

The way in which reply bodies are currently made when a non-200 response
code is set seems a little inconvenient. When no *http-error-handler* is
set, a standard body is given, and when a handler is set it is expected to
generate a body. I was creating a system where bad requests can be signalled
with conditions, which contain an error message that should be given to the
user, and which I was going to render by first calling send-headers and then
writing an html-templates template to the resulting stream... but my efforts
were frustrated by the fact that send-headers calls start-output, which
dumbly generates a body when an error code is set, and the
*http-error-handler* is a rather clumsy way to hook into this -- it doesn't
know anything about the context of the error, and communicating to it by
using a dynamic variable is rather ugly. Maybe an extra argument to (setf
return-code) which suppresses the generating of a standard body would be a
nicer way to allow people to customize their error messages. (Or maybe
having an accessors setf form take different arguments from its normal form
is very bad style. -- Another way could be to leave response-code the way it
is, default to not replacing the body in case of non-200 code, and add
another function which sets the response-code and also enables the
body-replacing functionality for that request.)

Regards,
Marijn Haverbeke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061116/4545c657/attachment.html>