October 2009 - tbnl-devel@common-lisp.net

[hunchentoot-devel] maybe bug + patch
by Richard KLINDA 06 Jun '10

06 Jun '10

Hello, I may have found a bug. After stopping an acceptor with STOP, one can't start it again with START, because the START method doesn't reset the value of acceptor-shutdown-p to NIL, so the listener returns/quits instantly. See the attached trivial patch, that fixes the issue for me, but maybe I'm just missing something here. -- Richard

3 2

[hunchentoot-devel] Backtrace display
by Jonathon McKitrick 27 Dec '09

27 Dec '09

I recall some time ago, the break and backtrace capability of Hunchentoot was removed, perhaps to make it less platform dependent. But I still find myself often trying to find the origin of cryptic error messages, and adding FORMAT and BREAK statements to narrow down the problem area. What is a good way to drop in support for, say, SBCL, so that an error will break into the debugger with a backtrace, or even dump the backtrace to the log file? -- Jonathon McKitrick

7 9

[hunchentoot-devel] updated version
by John Thingstad 22 Dec '09

22 Dec '09

Where is the the current SVN version of Hunchentoot that you are working on located? It seems the huncentoot version at www.weitz.de hasn't been updated in ages.

7 9

[hunchentoot-devel] Preventing Hunchentoot from parsing the POST-Data
by Christoph Senjak 28 Oct '09

28 Oct '09

Hello. I am still trying to get PHP (and cgi in general) work behind Hunchentoot. The implementation of Cyrus Harmon does (besides not providing some necessary env-vars) not pass the postdata to the cgi-script. Using raw-post-data seems not to work (even when saying :want-stream nil) and always return nil as far as I saw. Can I somehow tell hunchentoot not to read and parse the post-data, but leaving raw-post-data as a binary stream which I can pass to the cgi-handler? Regards, Christoph

4 4

[hunchentoot-devel] [PATCH] maybe-read-post-parameters should pass `request' to raw-post-data
by Desmond O. Chang 28 Oct '09

28 Oct '09

--- source/hunchentoot/request.lisp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/source/hunchentoot/request.lisp b/source/hunchentoot/request.lisp index 776113a..ed194c6 100644 --- a/source/hunchentoot/request.lisp +++ b/source/hunchentoot/request.lisp @@ -305,7 +305,7 @@ unknown character set ~A in request content type." (cond ((and (string-equal type "application") (string-equal subtype "x-www-form-urlencoded")) (form-url-encoded-list-to-alist - (split "&" (raw-post-data :external-format +latin-1+)) + (split "&" (raw-post-data :request request :external-format +latin-1+)) external-format)) ((and (string-equal type "multipart") (string-equal subtype "form-data")) -- 1.6.5

2 1

[hunchentoot-devel] Best way to run Hunchentoot on Port 80, Proxy-Module for Hunchentoot
by Christoph Senjak 19 Oct '09

19 Oct '09

Hello. As I am really annoyed by the confusing configuration-"possibilities" of apache, and as lighttpd doesnt support what I want to do in its stable release, I want to run hunchentoot in the first place. However, there are two problems: At first, I cannot run a usermode-process listening on port 80. I am using sbcl, so I could use sb-posix:setuid after starting hunchentoot and gaining port 80, removing root-privileges. Or I could forward port 80 to port 8000 via firewall policies. I would prefer the first possibility. The question is, if there is anything millitating against starting hunchentoot as root and then using setuid. I.e. any security issues that could result from it, anything that maybe wont work, etc. Another thing is the question if there is some proxy- or passthrough-module for hunchentoot. I still have some php-pages I want to host (even though I will use lighttpd rather than apache for this), and would therefore need to pass them to another server in the background. Regards, Christoph Senjak

4 7

[hunchentoot-devel] Customizing acceptor behaviour
by Sebastian Tennant 19 Oct '09

19 Oct '09

Hi there, I've managed to set up two acceptors which use different dispatch tables and write to different message log files by using packages and passing modified copies of LOG-MESSAGE-TO-FILE and LIST-REQUEST-DISPATCHER as keyword args when instantiating each acceptor (within each package). It works but there is a lot of code duplication going on so I decided to try and creating a third package (maytal) which does essentially the same thing in an abstracted way by subclassing TBNL:ACCEPTOR. I should point out that If I'm barking up the wrong tree entirely, it's because I'm new to CLOS (and relatively new to OOP in general). In short, I'm trying to create a package (maytal) which I can use in other packages like so: ;; set up and enter development environment package (in-package :cl-user) (defpackage "DEV-ENV" (:use :cl)) (in-package :dev-env) ;; dev-env::*dispatch-table* (defvar *dispatch-table* '()) ;; instantiate dev-env::*acceptor* (defvar *acceptor* (make-instance 'maytal::acceptor :port 49154 :msg-log-file "./messages/dev.log" :dispatch-table *dispatch-table*)) (tbnl:start *acceptor*) (msg 'info "DEV-ENV::*ACCEPTOR* started on port 49154") Here's my first stab at creating maytal: (in-package :cl-user) (defpackage "MAYTAL" (:use :cl)) (in-package :maytal) (defclass acceptor (tbnl:acceptor) ((msg-log-file :initarg :msg-log-file) (dispatch-table :initarg :dispatch-table))) (defmethod initialize-instance :after ((a acceptor) &key) ;; prepare local environment for closures (let ((mlf (slot-value a 'msg-log-file)) (dt (slot-value a 'dispatch-table))) ;; handy (i.e., short-name) message log function based on tbnl:log-message-to-file (defun msg (log-level format-string &rest format-arguments) (tbnl::with-log-file (stream mlf (tbnl::make-lock (symbol-name (gensym)))) (format stream "[~A~@[ [~A]~]] ~?~%" (tbnl::iso-time) log-level format-string format-arguments))) (setf (slot-value a 'tbnl::message-logger) 'msg) ;; annonymous request dispatcher function based on tbnl:list-request-dispatcher but ;; which uses a locally defined dispatch table variable (setf (slot-value a 'tbnl::request-dispatcher) (lambda (request) (loop for dispatcher in dt for action = (funcall dispatcher request) when action return (funcall action) finally (setf (tbnl:return-code tbnl:*reply*) tbnl:+http-not-found+))) )) Needless to say it doesn't work. The function 'msg' is defined in the maytal package rather than in the package which is current when an instance of maytal::acceptor is created (thus defeating the whole purpose of my efforts), and although the request dispatcher functions in different packages appear to use different dispatch tables, they don't actually work! ;;; (in-package :dev-env) (msg 'info "Acceptor ITI-DEV::*ACCEPTOR* started on port 49154") ;;; => Undefined function MSG called with arguments [...] (tbnl::acceptor-message-logger *acceptor*) ;;; => MAYTAL::MSG (tbnl::acceptor-request-dispatcher *acceptor*) ;;; => #<CCL:COMPILED-LEXICAL-CLOSURE (:INTERNAL (INITIALIZE-INSTANCE :AFTER (MAYTAL::ACCEPTOR))) #x91D16C6> Any and all help very much appreciated. Regards, Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

4 6

[hunchentoot-devel] acceptor-names not found
by Phil Marneweck 17 Oct '09

17 Oct '09

Has any body tried to use acceptor-names in hunchentoot define-easy-handler? I can only get the easy-handler to find the acceptor-name if I change (find (acceptor-name *acceptor*) acceptor-names :test #'eq)) to (find (acceptor-name *acceptor*) acceptor-names :test #'equal)) In the following function. (defun dispatch-easy-handlers (request) "This is a dispatcher which returns the appropriate handler defined with DEFINE-EASY-HANDLER, if there is one." (loop for (uri acceptor-names easy-handler) in *easy-handler-alist* when (and (or (eq acceptor-names t) (find (acceptor-name *acceptor*) acceptor-names :test #'eq)) .... As far as I have seen in my tests acceptor-names have to be strings(sequences) so changing eq to equal makes sense... Or am I smoking my socks again?

2 2

[hunchentoot-devel] Small patch for LispWorks 6 beta
by Nico de Jager 14 Oct '09

14 Oct '09

$ diff -u lispworks.lisp_orig lispworks.lisp_patched --- lispworks.lisp_orig 2009-09-30 11:42:22.000000000 +0200 +++ lispworks.lisp_patched 2009-09-30 19:06:22.118317238 +0200 @@ -90,14 +90,14 @@ (defun make-socket-stream (socket acceptor) "Returns a stream for the socket SOCKET. The ACCEPTOR argument is used to set the timeouts." - #-:lispworks5 + #+:lispworks4 (when (acceptor-write-timeout acceptor) (parameter-error "You need LispWorks 5 or higher for write timeouts.")) (make-instance 'comm:socket-stream :socket socket :direction :io :read-timeout (acceptor-read-timeout acceptor) - #+:lispworks5 #+:lispworks5 + #-:lispworks4 :write-timeout (acceptor-write-timeout acceptor) :element-type 'octet))

3 6

[hunchentoot-devel] Default external format
by Sebastian Tennant 12 Oct '09

12 Oct '09

Hi list, I don't often see messages of thanks on open source software mailing lists, so, without wishing to sound obsequious, let me buck the trend by thanking Edi, and everone else, before and since, for their work on hunchentoot. I've found that setting this at the top level of cl-user: (setf tbnl:*hunchentoot-default-external-format* tbnl::+utf-8+) has no effect, other than preventing an error when a handler produces non-ascii text, i.e., the non-ascii text is garbled when displayed in the browser, despite including the line: (setf (tbnl:content-type*) "text/html; charset=utf-8") in the handler. The problem is solved by also including the line: (setf (tbnl:reply-external-format tbnl:*REPLY*) tbnl::+utf-8+) in the handler, so what then is the purpose if the special variable? Am I missing something? Regards Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap

4 8