<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[Please use the mailing list.]</blockquote><div><br>Sorry about that, happened by accident.
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It was intended as a simple solution at a time when there was no<br>customized error handling at all:
<br><br>  <a href="http://common-lisp.net/pipermail/tbnl-devel/2005-March/000197.html">http://common-lisp.net/pipermail/tbnl-devel/2005-March/000197.html</a><br><br>I still think it is OK as far as it is in line with the way "normal"
<br>content is handled in Hunchentoot.  The only real difference I can see<br>is that you can't write directly to a stream.<br><br>Why you can't use your nice function escapes me, though.  You could<br>capture its output in a string stream, couldn't you?
</blockquote><div><br>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.)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If you come up with a solution that obviously improves the current<br>situation, I'd be happy to include your patches.  Bonus points if the
<br>new stuff is compatible with the old code.  And note that a patch<br>which changes user-visible behaviour should include documentation as<br>well - I might otherwise reject it.</blockquote><div><br>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?
<br></div></div><br>Marijn<br>