I have (finally!) updated my local installation of hunchentoot. Testing indicates that things work as expected, except for one thing: calling (setf (hunchentoot:reply-external-format*) ...) in a request handler causes the request to abort. This is probably not a big issue, since I probably don't need to set the external format (it appears to get the right value automatically).
I'm reporting it here because it may actually be caused by a bug; alternatively, it could be that I'm doing something stupid, which would then be useful to know.
The code snippet below works (after making an easy-acceptor). Removing the #+nil causes it to break.
(hunchentoot:define-easy-handler (test :uri "/test") (foo) (setf (hunchentoot:content-type*) "text/plain") #+nil (setf (hunchentoot:reply-external-format*) :utf-8) (format nil "Host: ~a~%Proto: ~a (~a)~%Script: ~a~%requrl: ~a~%foo: ~a" (hunchentoot:host) (hunchentoot:server-protocol*) (type-of (hunchentoot:server-protocol*)) (hunchentoot:script-name*) (hunchentoot:request-uri*) foo))
Update: I checked the value of hunchentoot:*hunchentoot-default-external-format*, which gave me a hint that I needed to pass something else than just a keyword symbol...
(setf (hunchentoot:reply-external-format*) (flexi-streams:make-external-format :utf-8))
appears to work.
In case it matters: this is using Lispworks 6.0.1 (Professional, 32-bit) under Windows 7.
On Tue, Jan 10, 2012 at 3:24 PM, Raymond Wiker rwiker@gmail.com wrote:
I have (finally!) updated my local installation of hunchentoot. Testing indicates that things work as expected, except for one thing: calling (setf (hunchentoot:reply-external-format*) ...) in a request handler causes the request to abort. This is probably not a big issue, since I probably don't need to set the external format (it appears to get the right value automatically).
I'm reporting it here because it may actually be caused by a bug; alternatively, it could be that I'm doing something stupid, which would then be useful to know.
The code snippet below works (after making an easy-acceptor). Removing the #+nil causes it to break.
(hunchentoot:define-easy-handler (test :uri "/test") (foo) (setf (hunchentoot:content-type*) "text/plain") #+nil (setf (hunchentoot:reply-external-format*) :utf-8) (format nil "Host: ~a~%Proto: ~a (~a)~%Script: ~a~%requrl: ~a~%foo: ~a" (hunchentoot:host) (hunchentoot:server-protocol*) (type-of (hunchentoot:server-protocol*)) (hunchentoot:script-name*) (hunchentoot:request-uri*) foo))
Hello Raymond,
can you let us know what you mean by "abort". An error message and backtrace would be most helpful.
Thanks, Hans
On Tue, Jan 10, 2012 at 3:27 PM, Raymond Wiker rwiker@gmail.com wrote:
Update: I checked the value of hunchentoot:*hunchentoot-default-external-format*, which gave me a hint that I needed to pass something else than just a keyword symbol...
(setf (hunchentoot:reply-external-format*) (flexi-streams:make-external-format :utf-8))
appears to work.
In case it matters: this is using Lispworks 6.0.1 (Professional, 32-bit) under Windows 7.
On Tue, Jan 10, 2012 at 3:24 PM, Raymond Wiker rwiker@gmail.com wrote:
I have (finally!) updated my local installation of hunchentoot. Testing indicates that things work as expected, except for one thing: calling (setf (hunchentoot:reply-external-format*) ...) in a request handler causes the request to abort. This is probably not a big issue, since I probably don't need to set the external format (it appears to get the right value automatically).
I'm reporting it here because it may actually be caused by a bug; alternatively, it could be that I'm doing something stupid, which would then be useful to know.
The code snippet below works (after making an easy-acceptor). Removing the #+nil causes it to break.
(hunchentoot:define-easy-handler (test :uri "/test") (foo) (setf (hunchentoot:content-type*) "text/plain") #+nil (setf (hunchentoot:reply-external-format*) :utf-8) (format nil "Host: ~a~%Proto: ~a (~a)~%Script: ~a~%requrl: ~a~%foo: ~a" (hunchentoot:host) (hunchentoot:server-protocol*) (type-of (hunchentoot:server-protocol*)) (hunchentoot:script-name*) (hunchentoot:request-uri*) foo))
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Jan 10, 2012, at 15:34 , Hans Hübner wrote:
Hello Raymond,
can you let us know what you mean by "abort". An error message and backtrace would be most helpful.
Thanks, Hans
That's the problem - I don't get an error message, and no stacktrace - the closest I get to an error indication is the web browser saying "the server dropped the connection" or something like that... I guess that could be a mismatch between content-length and actual content? Caused by different ideas of what the line-ending protocol is?
I'll make a more concentrated effort to find out where it fails.
You may want to use HUNCHENTOOT:*CATCH-ERRORS-P* and/or CL:*BREAK-ON-SIGNALS* to get more information about the error.
-HAns
On Tue, Jan 10, 2012 at 4:40 PM, Raymond Wiker rwiker@gmail.com wrote:
On Jan 10, 2012, at 15:34 , Hans Hübner wrote:
Hello Raymond,
can you let us know what you mean by "abort". An error message and backtrace would be most helpful.
Thanks, Hans
That's the problem - I don't get an error message, and no stacktrace - the closest I get to an error indication is the web browser saying "the server dropped the connection" or something like that... I guess that could be a mismatch between content-length and actual content? Caused by different ideas of what the line-ending protocol is?
I'll make a more concentrated effort to find out where it fails. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Jan 10, 2012, at 16:44 , Hans Hübner wrote:
You may want to use HUNCHENTOOT:*CATCH-ERRORS-P* and/or CL:*BREAK-ON-SIGNALS* to get more information about the error.
On a fresh Lispworks instance, on my MacBook, I get a heap of messages like
[2012-01-10 17:13:59 [ERROR]] Error while processing connection: No applicable methods for #<STANDARD-GENERIC-FUNCTION FLEXI-STREAMS:EXTERNAL-FORMAT-NAME 21A56722> with args (:UTF8)
--- sooo, it appears that Hunchentoot is only prepared to accept a flexi-streams:external-format, and not just a keyword symbol. I have the explanation I needed, and at least two acceptable fixes :-)
Thanks, and sorry for the noise.
-
Hans Hübner -
Raymond Wiker