Hi,
I have just released Hunchentoot 1.2.14. This release changes how ACCEPTOR-STATUS-MESSAGE is called. Previously, ACCEPTOR-STATUS-MESSAGE was invoked for all requests, after the handler had been invoked. If it returned non-NIL, the content returned by the handler was discarded. This did not actually make sense, and I have changed it so that ACCEPTOR-STATUS-MESSAGE is only called when the handler did not return contents. That way, handlers are now free to create their own status message bodies, if desired.
This is a incompatible change, so if you depended on the previous invocation sequence, please review your code before upgrading.
The work was funded by Ron Garret, thanks for that!
-Hans
Quoth Hans Hübner hans.huebner@gmail.com:
[...] I have changed it so that ACCEPTOR-STATUS-MESSAGE is only called when the handler did not return contents.
Can you be more specific? For example, must a handler return NIL for ACCEPTOR-STATUS-MESSAGE to be called, or will ACCEPTOR-STATUS-MESSAGE also be called if the handler returns the empty string?
Sebastian
"did not return contents" means NIL. If you think that the manual needs clarification, feel free to send a pull request.
-Hans
On Sat, Mar 30, 2013 at 9:15 PM, Sebastian Tennant sebyte@smolny.plus.comwrote:
Quoth Hans Hübner hans.huebner@gmail.com:
[...] I have changed it so that ACCEPTOR-STATUS-MESSAGE is only called
when
the handler did not return contents.
Can you be more specific? For example, must a handler return NIL for ACCEPTOR-STATUS-MESSAGE to be called, or will ACCEPTOR-STATUS-MESSAGE also be called if the handler returns the empty string?
Sebastian
Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel