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

[Marijn Haverbeke]

>
> [Please use the mailing list.]


Sorry about that, happened by accident.

It was intended as a simple solution at a time when there was no
> customized error handling at all:
>
>   http://common-lisp.net/pipermail/tbnl-devel/2005-March/000197.html
>
> I still think it is OK as far as it is in line with the way "normal"
> content is handled in Hunchentoot.  The only real difference I can see
> is that you can't write directly to a stream.
>
> Why you can't use your nice function escapes me, though.  You could
> capture its output in a string stream, couldn't you?


It currently  created its own output stream by calling send-headers. I could
add some scaffolding to work around this and allow it to output a string,
but it clashes horribly with the structure of my code, and in this case it
feels like it's the library, not the way my code works, which is making
things difficult. (I might be a bit compulsive-obsessive here, I'll admit.)

If you come up with a solution that obviously improves the current
> situation, I'd be happy to include your patches.  Bonus points if the
> new stuff is compatible with the old code.  And note that a patch
> which changes user-visible behaviour should include documentation as
> well - I might otherwise reject it.


The least-intrusive form I can think of now is to add another configuration
special variable, named *handle-error-codes* or something similar (is error
code a good term for non-200 responses at all?). This one defaults to t, but
when it is set to nil then start-output does not interfere with the bodies
of non-200 responses. If this sounds ok to you I'll implement it tomorrow.
What is the preferred way to submit patches to the docs?

Marijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20061117/6ba165f6/attachment.html>