[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