May 2007 - tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[hunchentoot-devel] Hunchentoot not working on OpenMCL 1.1pre
by Tiarnan O'Corrain 03 Nov '07

03 Nov '07

Hi-- I've just installed a brand new OpenMCL pre-prelease ("Version 1.1-pre-070512 (DarwinPPC32)") and am getting the following error in the browser when accessing the default hunchentoot page: NIL Unknown http return code: 200 A backtrace from SLIME is given below. Originally I thought the problem was due to a reference in port-mcl.lisp to ccl::make-timer-request: I installed acl-compat, which provides this, with no change in outcome. Any pointers to fruitful areas of investigation would be appreciated. regards Tiarnán Stream #<BASIC-FILE-BINARY-OUTPUT-STREAM ("/tmp/hunchentoot.log"/24 ISO-8859-1) #x93BC97E> is private to #<PROCESS hunchentoot-worker-1(48) [Exhausted] #x93BBC1E> [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT-BREAK] Reset this process 1: [ABORT] Kill this process Backtrace: 0: (#<Anonymous Function #x85C7C2E> 0 20) 1: (SWANK:BACKTRACE 1 41) 2: (CCL::CALL-CHECK-REGS 'SWANK:BACKTRACE) 3: (#<Anonymous Function #x86434AE> '(SWANK:BACKTRACE 1 41) 44 'NIL) 4: (#<Anonymous Function #x85687F6> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x863C6A6> #<COMPILED-LEXICAL-CLOSURE #x93EE3CE>) 5: (FUNCALL 'SWANK::EVAL-FOR-EMACS) 6: (SWANK::SLDB-LOOP '(70 T 10 T NIL 10 T #S(CCL::PPRINT-DISPATCH-TABLE :CONSES-WITH-CARS #<HASH-TABLE :TEST EQ size 60/60 #x85DEBB6> :STRUCTURES NIL :OTHERS (#<CCL::ENTRY #x846914E> #)) NIL T ...)) 7: (SWANK::CALL-WITH-BINDINGS '((*PRINT-PRETTY* . T) (*PRINT-LEVEL* . 4) (*PRINT-LENGTH* . 10) (*PRINT-CIRCLE* . T) (*PRINT-READABLY*) (*PRINT-PPRINT-DISPATCH* . #S(CCL::PPRINT-DISPATCH-TABLE :CONSES-WITH-CARS #<HASH-TABLE :TEST EQ size 60/60 #x85DEBB6> :STRUCTURES NIL :OTHERS (# #))) (*PRINT-GENSYM* . T) (*PRINT-BASE* . 10) (*PRINT-RADIX*) (*PRINT-ARRAY* . T) ...) #<Anonymous Function #x863B636>) 8: (#<Anonymous Function #x85C8B56> #<Anonymous Function #x863B686>) 9: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR #x93DEBA6>) 10: (#<Anonymous Function #x85687F6> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x863C6A6> #<COMPILED-LEXICAL-CLOSURE #x93DEB56>) 11: (SWANK::CALL-WITH-REDIRECTED-IO #<COMPILED-LEXICAL-CLOSURE #x93DEB3E> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x863C6A6>) 12: (SWANK::CALL-WITH-CONNECTION #<CONNECTION #x869E2CE> #<COMPILED-LEXICAL-CLOSURE #x93DEB56>) 13: (INVOKE-DEBUGGER #<SIMPLE-ERROR #x93DEBA6>) 14: (SIGNAL #<SIMPLE-ERROR #x93DEBA6>) 15: (CCL::%ERROR '(#<BASIC-FILE-BINARY-OUTPUT-STREAM ("/tmp/hunchentoot.log"/24 ISO-8859-1) #x93BC97E> #<PROCESS hunchentoot-worker-1(48) [Exhausted] #x93BBC1E>) -65534292) 16: (CCL::%PRIVATE-IOBLOCK-WRITE-U8-BYTE 91 #<BASIC-FILE-BINARY-OUTPUT-STREAM ("/tmp/hunchentoot.log"/24 ISO-8859-1) #x93BC97E>) 17: (WRITE-BYTE 91 'FLEXI-STREAMS::WRITE-BYTE*) Locals: CCL::IOBLOCK = #S(CCL::FILE-IOBLOCK :STREAM #<BASIC-FILE-BINARY-OUTPUT-STREAM ("/tmp/hunchentoot.log"/24 ISO-8859-1) #x93BC97E> :UNTYI-CHAR NIL :INBUF NIL :OUTBUF #<IO-BUFFER (UNSIGNED-BYTE 8) 0/0/2048 #x93BC86E> :ELEMENT-TYPE ...) 18: (#<STANDARD-METHOD STREAM-WRITE-CHAR (FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM T)> #\[ '(NIL #<STANDARD-METHOD STREAM-WRITE-CHAR (FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM T)> . 8955664)) 19: (CCL::%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE '(NIL #<STANDARD-METHOD STREAM-WRITE-CHAR (FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM T)> . 8955664)) 20: (CCL::%%STANDARD-COMBINED-METHOD-DCODE 0 #\[) 21: (#<STANDARD-METHOD TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE (FLEXI-STREAMS:FLEXI-OUTPUT-STREAM T T T)> #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E> "[~A~@[ [~A]~]] ~A~%" 0 1) 22: (WRITE-STRING "[~A~@[ [~A]~]] ~A~%" #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E>) Locals: OUTPUT-STREAM = #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E> CCL::START = 0 CCL::END = 1 23: (CCL::SUB-FORMAT #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E> 0 19) 24: (CCL::DO-SUB-FORMAT #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E>) 25: (FORMAT #<FLEXI-STREAMS::FLEXI-UTF-8-OUTPUT-STREAM #x93BC72E> "[~A~@[ [~A]~]] ~A~%") 26: (#<STANDARD-METHOD HUNCHENTOOT:LOG-MESSAGE (T T)> ':INFO "Default handler called for script ~A") Locals: HUNCHENTOOT::LOG-LEVEL = :INFO HUNCHENTOOT::FMT = "Default handler called for script ~A" HUNCHENTOOT::ARGS = ("/hunchentoot/") HUNCHENTOOT::MESSAGE = "Default handler called for script /hunchentoot/" CCL::*INTERRUPT-LEVEL* = 0 CCL::*INTERRUPT-LEVEL* = -1 CCL::%HANDLERS% = ((ERROR #1=#<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06> WARNING #<COMPILED-LEXICAL-CLOSURE #x93DECEE>) (ERROR #1#) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E> WARNING #<Anonymous Function #x8F56EC6>) (PROCESS-RESET)) #:G3734 = (ERROR #<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>) CCL::%HANDLERS% = ((ERROR) (ERROR #1=#<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06> WARNING #<COMPILED-LEXICAL-CLOSURE #x93DECEE>) (ERROR #1#) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E> WARNING #<Anonymous Function #x8F56EC6>) (PROCESS-RESET)) CCL::%HANDLERS% = ((ERROR #1=#<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>) (ERROR) (ERROR #1#) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06> WARNING #<COMPILED-LEXICAL-CLOSURE #x93DECEE>) (ERROR #1#) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E> WARNING #<Anonymous Function #x8F56EC6>) (PROCESS-RESET)) CCL::%HANDLERS% = ((ERROR) (ERROR #1=#<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>) (ERROR) (ERROR #1#) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06> WARNING #<COMPILED-LEXICAL-CLOSURE #x93DECEE>) (ERROR #1#) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E> WARNING #<Anonymous Function #x8F56EC6>) ..) Catch-tags: NIL NIL NIL 27: (HUNCHENTOOT::DEFAULT-HANDLER) [No Locals] 28: (HUNCHENTOOT::PROCESS-REQUEST '((:HOST . "localhost:4242") (:USER-AGENT . "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3") (:ACCEPT . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5") (:ACCEPT-LANGUAGE . "en-us,en;q=0.5") (:ACCEPT-ENCODING . "gzip,deflate") (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7") (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive") (:CACHE-CONTROL . "max-age=0")) #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM #x93DF4B6> ':GET "/hunchentoot/" ':HTTP/1.1) Locals: HUNCHENTOOT:HEADERS-IN = ((:HOST . "localhost:4242") (:USER-AGENT . "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3") (:ACCEPT . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5") (:ACCEPT-LANGUAGE . "en-us,en;q=0.5") (:ACCEPT-ENCODING . "gzip,deflate") (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7") (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive") (:CACHE-CONTROL . "max-age=0")) HUNCHENTOOT::CONTENT-STREAM = #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM #x93DF4B6> METHOD = :GET HUNCHENTOOT::URL-STRING = "/hunchentoot/" HUNCHENTOOT:SERVER-PROTOCOL = :HTTP/1.1 HUNCHENTOOT::*TMP-FILES* = NIL HUNCHENTOOT::*HEADERS-SENT* = NIL CCL::*INTERRUPT-LEVEL* = 0 CCL::*INTERRUPT-LEVEL* = -1 HUNCHENTOOT:*SESSION* = #<Unbound> HUNCHENTOOT:*REPLY* = #<Unbound> HUNCHENTOOT:*REQUEST* = #<Unbound> HUNCHENTOOT:*DISPATCH-TABLE* = (HUNCHENTOOT:DEFAULT-DISPATCHER) HUNCHENTOOT::BACKTRACE = #<VALUE-CELL NIL #x93DED1E> CCL::%HANDLERS% = ((ERROR #<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E> WARNING #<Anonymous Function #x8F56EC6>) (PROCESS-RESET)) CCL::%HANDLERS% = ((ERROR #<COMPILED-LEXICAL-CLOSURE #x93DED06> WARNING #<COMPILED-LEXICAL-CLOSURE #x93DECEE>) (ERROR #<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>) (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E> WARNING #<Anonymous Function #x8F56EC6>) (PROCESS-RESET)) Catch-tags: HUNCHENTOOT:HANDLER-DONE NIL 29: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER #x93BBAC6> #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/23) #x93DC88E>) Locals: HUNCHENTOOT::SERVER = #<HUNCHENTOOT::SERVER #x93BBAC6> HUNCHENTOOT::HANDLE = #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/23) #x93DC88E> #:COMPILER-VAR = (NIL) #:G4134 = (ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E> WARNING #<Anonymous Function #x8F56EC6>) CCL::%HANDLERS% = ((PROCESS-RESET)) #:G4135 = (ERROR #<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER #x8A9D2B6>) CCL::%HANDLERS% = ((ERROR #<COMPILED-LEXICAL-CLOSURE #x93E156E> WARNING #<Anonymous Function #x8F56EC6>) (PROCESS-RESET)) HUNCHENTOOT::*HUNCHENTOOT-STREAM* = #<Unbound> HUNCHENTOOT::*LOCAL-HOST* = #<Unbound> HUNCHENTOOT::*REMOTE-HOST* = #<Unbound> HUNCHENTOOT::*REMOTE-PORT* = #<Unbound> CCL::*INTERRUPT-LEVEL* = 0 CCL::*INTERRUPT-LEVEL* = -1 HUNCHENTOOT:*SERVER* = #<Unbound> CCL::*INTERRUPT-LEVEL* = 0 CCL::*INTERRUPT-LEVEL* = -1 HUNCHENTOOT::*CLOSE-HUNCHENTOOT-STREAM* = NIL HUNCHENTOOT:HEADERS-IN = ((:HOST . "localhost:4242") (:USER-AGENT . "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3") (:ACCEPT . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5") (:ACCEPT-LANGUAGE . "en-us,en;q=0.5") (:ACCEPT-ENCODING . "gzip,deflate") (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7") (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive") (:CACHE-CONTROL . "max-age=0")) HUNCHENTOOT::CONTENT-STREAM = #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM #x93DF4B6> METHOD = :GET HUNCHENTOOT::URL-STRING = "/hunchentoot/" HUNCHENTOOT:SERVER-PROTOCOL = :HTTP/1.1 Catch-tags: NIL NIL NIL 30: (CCL::RUN-PROCESS-INITIAL-FORM '(#<COMPILED-LEXICAL-CLOSURE #x93DC32E>) #<PROCESS hunchentoot-worker-2(49) [Active] #x93DC366>) 31: (#<Anonymous Function #x8174C16> '(#<COMPILED-LEXICAL-CLOSURE #x93DC32E>) 0) 32: (#<Anonymous Function #x815EF56> 790464 #<LISP-THREAD hunchentoot-worker-2 [tcr @ #x303F00] #x93DC4DE>)

3 2

[hunchentoot-devel] host/port question
by Cyrus Harmon 18 Jul '07

18 Jul '07

I'm not sure what "the right thing" here is, but it struck me as odd that redirect didn't include a port argument, so I made the following changes to redirect: --- hunchentoot-0.9.0/misc.lisp 2007-03-30 14:01:27.000000000 -0700 +++ ../hunchentoot-0.9.0/misc.lisp 2007-04-27 22:45:00.000000000 -0700 @@ -229,6 +229,7 @@ (add-session-id (not (or host-provided-p (starts-with- scheme-p target) (cookie-in *session-cookie-name*)))) + port permanently) "Redirects the browser to TARGET which should be a string. If TARGET is a full URL starting with a scheme, HOST and PROTOCOL @@ -240,11 +241,11 @@ otherwise a 302." (let ((url (if (starts-with-scheme-p target) target - (format nil "~A://~A~A" + (format nil "~A://~A~@[:~A~]~A" (ecase protocol ((:http) "http") ((:https) "https")) - host target)))) + host port target)))) (when add-session-id (setq url (add-cookie-value-to-url url :replace-ampersands-p nil))) (setf (header-out :location) but then I realized that what we call "host" here really is host:port. Should these two notions be more "decoupled" or should I just think host:port when I see host? Thanks, Cyrus

2 4

[hunchentoot-devel] Custom types for easy handler.
by Timothy Schaeffer 01 Jun '07

01 Jun '07

Hello all, I propose that the types for easy-handlers be extensible by the users. I have pieces of markup which are used throughout our site which collect information from several fields into a class (in our case tied to a database with clsql). The names of the fields are related, but diffierent from the lists, arrays and hashes of the easy-handlers, Dates and addresses are two good examples, but there are others. I would like to be able to teach the easy handler to collect these for me and pass them as parameters. This cannot be done with functions as the :parameter-type because the functions passed as :parameter-type do not take the parameter name. There are two ways I think this could be done: - The easier way: add a :paramater-reader arg to the parameter description, and if passed use it in lieu of the ((post|get)-)?parameter functions in compute-parameter. The following might do it (untested): (defun compute-parameter (parameter-name parameter-type request-type &optional parameter-reader) ; <===== "Computes and returns the parameter\(s) called PARAMETER-NAME and converts it/them according to the value of PARAMETER-TYPE. REQUEST-TYPE is one of :GET, :POST, or :BOTH." (when (member parameter-type '(list array hash-table)) (setq parameter-type (list parameter-type 'string))) (let ((parameter-reader (or parameter-reader ; <==== (ecase request-type (:get #'get-parameter) (:post #'post-parameter) (:both #'parameter))) ) (parameters (and (listp parameter-type) (case request-type (:get (get-parameters)) (:post (post-parameters)) (:both (append (get-parameters) (post-parameters))))))) (cond ((atom parameter-type) (compute-simple-parameter parameter-name parameter-type parameter-reader)) ((and (null (cddr parameter-type)) (eq (first parameter-type) 'list)) (compute-list-parameter parameter-name (second parameter-type) parameters)) ((and (null (cddr parameter-type)) (eq (first parameter-type) 'array)) (compute-array-parameter parameter-name (second parameter-type) parameters)) ((and (null (cddddr parameter-type)) (eq (first parameter-type) 'hash-table)) (compute-hash-table-parameter parameter-name (second parameter-type) parameters (or (third parameter-type) 'string) (or (fourth parameter-type) 'equal))) (t (error "Don't know what to do with parameter type ~S." parameter-type))))) (defun make-defun-parameter (description default-parameter-type default-request-type) "Creates a keyword parameter to be used by DEFINE-EASY-HANDLER. DESCRIPTION is one of the elements of DEFINE-EASY-HANDLER's LAMBDA-LIST and DEFAULT-PARAMETER-TYPE and DEFAULT-REQUEST-TYPE are the global default values." (when (atom description) (setq description (list description))) (destructuring-bind (parameter-name &key (real-name (compute-real-name parameter-name)) parameter-type init-form request-type parameter-reader ) ; <==== description `(,parameter-name (or (and (boundp '*request*) (compute-parameter ,real-name ,(or parameter-type default-parameter-type) ,(or request-type default-request-type))) ,init-form)))) (This just occurred to me: request-type could be a function, with an obvious change to the ecase. This is a little more confusing but consistent with what parameter-type does---so it has the force of precedent---and requires a smaller change to the code.). - The extensive way: Change the cond in compute-parameter to a switch via a hash table, whose values are the conversion handlers (or a cons with reader and converter). It may need two hash tables: one for simple type names (type is a symbol) and one for aggregates, (type is a cons, and switch on the first element). Create a macro, define-easy-type, or something, to populate the tables, and use it within easy-handlers.lisp to populate it with those which are now hardcoded in the cond and case switches. Users can then use the macro to define their own types. - Another way: like above, but use methods instead of hash tables. This seems possible, but I'd have to think some more about it. BTW: why the checks for null CDDRs and CDDDDRs in compute-parameter? Is this just nice, or are they essential? If your interested in the second, I will work something up and send in a patch. I do not think it would break any existing code which did not peak too far into the easy-handlers stuff. Let me know what you think. Tim S P.S.: Hunchentoot is a pleasure to work with!

3 2

[hunchentoot-devel] Re: Hunchentoot REST framework
by Edi Weitz 29 May '07

29 May '07

Hi, On Tue, 29 May 2007 15:35:58 +0200, Nicolas Lamirault <lam(a)tuxfamily.org> wrote: > i'm re-working on this framework and i've got a few problems ... I'd prefer if we could continue this discussion on the mailing list - see Cc. > i try to get parameters when a make a PUT request : > > $> curl -X PUT -d name=nicolas http://localhost:8888/ht-rest/test/user/lam@foo.org If you use curl like this, it will send the parameters as application/x-www-form-urlencoded in the request body. I can't see how it would make sense to use a PUT request for this. In a PUT request, the request body is supposed to be the entity that is to be stored under the request URI. > on logs i have this : > > [2007-05-29 15:30:19 [INFO]] Put User > [2007-05-29 15:30:19 [INFO]] PUT parameters NIL Where do these log entries come from? > and i create a function : > > (defun rest-put-parameter (name) > "Returns the value of the PUT parameter named by the string NAME as > a string or NIL if there ain't no PUT parameter with this name." > (hunchentoot:aux-request-value (make-symbol name))) > > but my function doesn't work ... > I think my mistake comes from i don't really understand how use the > aux-request-value function. Yes, it looks so. AUX-REQUEST-VALUE is meant so you can /store/ arbitrary values associated with the request and later retrieve them. I have no idea what REST-PUT-PARAMETER is supposed to do or what a "PUT parameter" is. > have u got any idea for this problem ? I don't understand the problem... Did you look at CL-WEBDAV to see how it handles PUT requests as I told you? Cheers, Edi.

1 0

[hunchentoot-devel] gzip-encoding
by Mac Chan 28 May '07

28 May '07

With this web 2.0 thing, nowadays it's not uncommon to have javascript library weighting over 500k (with extreme case like dojo which adds up to several megabytes). If you google a bit you'll find that this doesn't concern the toolkit authors because they'll say that if you minimize (eliminate whitespaces) the javascript file and turn on gzip encoding it's a non-issue. It was a low-hanging fruit to add gzip-encoding to hunchentoot since the hard work has already been done by Edi's (flexi-stream), Zach (Salza 1) and Sean Ross (gzip-stream 2). In fact it was only a few lines of changes. Using the network monitor in FireBug , my initial testing (with a 790 KB javascript file) shows that the response time is slower with gzip turned on (I'm guessing that it might be related to flexi-stream.) 262 KB 828ms 875ms 735ms 703ms 719ms 593ms 734ms 790 KB 625ms 359ms 672ms 328ms 610ms 641ms 594ms Since I'm testing with the loopback interface, there's virtually no network overhead. So I launch another firefox in vmware and limit the download rate of the network interface to 150k (the most common DSL speed offered in the states) 262 KB 1.72s 1.72s 1.64s 1.79s 790 KB 5.16s 5.21s 5.11s 5.21s Now we're talking. And we can't ignore the 56k line users, can't we? 262 KB 8.39s 5.07s 4.97s 5.07s 790 KB 15.36s … point taken, I don't want to repeat this :-) So now, the questions remain: Should we add this to hunchentoot or make it an extension module? (this will introduce two new dependencies to hunchentoot) If we add this to hunchentoot, should we add a flag to turn on/off gzip encoding? (probably yes) And again, since there's flexi-stream overhead (my guess), should we add a flag to control what content-type we should disable gzip encoding? (probably wasting cpu cycle to gzip jpeg, mp3 and png, etc). Suggestions? -- Mac 1: http://www.cliki.net/Salza 2: http://common-lisp.net/project/gzip-stream/ (defun handle-static-file (path &optional content-type) "A function which acts like a Hunchentoot handler for the file denoted by PATH. Send a content type header corresponding to CONTENT-TYPE or \(if that is NIL) tries to determine the content type via the file's suffix." (unless (or (pathname-name path) (pathname-type path)) ;; not a file (setf (return-code) +http-bad-request+) (throw 'handler-done nil)) (unless (probe-file path) ;; does not exist (setf (return-code) +http-not-found+) (throw 'handler-done nil)) (let ((time (or (file-write-date path) (get-universal-time))) (accept-gzip-p (search "gzip" (header-in :accept-encoding)))) (setf (content-type) (or content-type (mime-type path) "application/octet-stream")) (handle-if-modified-since time) (with-open-file (file path :direction :input :element-type '(unsigned-byte 8) :if-does-not-exist nil) (setf (header-out "Last-Modified") (rfc-1123-date time)) (if accept-gzip-p (setf (header-out "Content-Encoding") "gzip") (setf (content-length) (file-length file))) (let ((out (send-headers))) (when accept-gzip-p (setq out (gzip-stream:make-gzip-output-stream out))) (loop with buf = (make-array +buffer-length+ :element-type '(unsigned-byte 8)) for pos = (read-sequence buf file) until (zerop pos) do (write-sequence buf out :end pos) (finish-output out))))))

2 2

[hunchentoot-devel] Hunchentoot and OpenMCL
by Lennart Staflin 26 May '07

26 May '07

Hi, I have been using OpenMCL and portable aserve. I ran into some trouble with character encoding, and after looking at the code decided that it would be difficult to fix. I am now considering alternatives. I read somewhere that Hunchentoot runs on OpenMCL so I'm going to try it out. Any experience with running Hunchentoot on OpenMCL, specially the bleeding edge OpenMCL? Any experience converting a project from aserve to Hunchentoot? Also I ran into a compile problem: ;Compiler warnings : ; Undefined function CCL::DEQUEUE-TIMER-REQUEST, in INVOKE-WITH-TIMEOUT. ; Undefined function CCL::ENQUEUE-TIMER-REQUEST, in INVOKE-WITH-TIMEOUT. ; Undefined function CCL::MAKE-TIMER-REQUEST, in INVOKE-WITH-TIMEOUT. from port-mcl.lisp: (defun invoke-with-timeout (seconds bodyfn timeoutfn) "Executes the function \(with no arguments) BODY-FN and returns its results but stops execution after DURATION seconds and then instead calls TIMEOUT-FN and returns its values." ;; from Portable AllegroServe (block timeout (let* ((timer (ccl::make-timer-request seconds #'(lambda () (return-from timeout (funcall timeoutfn)))))) (ccl::enqueue-timer-request timer) (unwind-protect (funcall bodyfn) (ccl::dequeue-timer-request timer))))) Probably the timer functions have been removed in some of the later versions of OpenMCL. Unless someone has a fix already I will dig into this. -- //Lennart Staflin

3 5

[hunchentoot-devel] Lisp server page for hunchentoot
by Mac Chan 25 May '07

25 May '07

I ported John Wiseman's lsp for use by hunchentoot. You can check out the source from the contrib directory : svn checkout svn://common-lisp.net/project/tbnl/svn http://common-lisp.net/websvn/listing.php?repname=tbnl&path=%2Fcontrib%2Fls… Comments welcomed. Cheers, -- Mac The following are copied verbatim from the comment (asdf:oos 'asdf:load-op :cl-ppcre) (asdf:oos 'asdf:load-op :hunchentoot-test) (hunchentoot:start-server :port 8080) ;; verify that hunchentoot is running ;; http://localhost:8080/hunchentoot/test/ (asdf:oos 'asdf:load-op :lsp) (in-package :lsp) ;; set debug on so we can examine the generated code (set-lsp-debug t) ;; use cl-user package for all unqualified symbols (set-lsp-package :cl-user) ;; compile the test file (get-lsp-function (merge-pathnames "test.lsp" *this-dir*)) ;; take a look at the generated code (show-lsp-form (merge-pathnames "test.lsp" *this-dir*)) ;; print the output to REPL (do-lsp-request (merge-pathnames "test.lsp" *this-dir*)) ;; install the dispatcher function (push (create-lsp-folder-dispatcher-and-handler ;; uri "/hunchentoot/lsp/" ;; directory *this-dir* ;; valid lsp page suffixes '("lsp" "lhtml" "lhtm" "asp") ;; default content-type for non lsp files "text/plain") hunchentoot:*dispatch-table*) ;; try it out (click refresh a few times to verify that it is _dynamic_) ;; http://localhost:8080/hunchentoot/lsp/test.lsp ;; take a look at the source code too ;; http://localhost:8080/hunchentoot/lsp/lsp.lisp ;; alternatively, you can also create separate handler for each lsp file (push (hunchentoot:create-prefix-dispatcher "/hunchentoot/lsp/test.lsp" (get-lsp-function (merge-pathnames "test.lsp" *this-dir*))) hunchentoot:*dispatch-table*) ;; finally, you can also reuse lsp function within a custom dispatch handler (hunchentoot:define-easy-handler (lsp-demo :uri "/hunchentoot/test/lsp-demo.html") () (do-lsp-request (merge-pathnames "test.lsp" *this-dir*))) ;; http://localhost:8080/hunchentoot/test/lsp-demo.html LAQ: * Why another template module? There are indeed a lot of template libraries including CL-EMB, Edi's own HTML-TEMPLATE, etc. But these libraries are obstinate in that they require you to construct and pass the `environment' variable in order to generate the dynamic content. Secondly, I found that the @if @else template extensions/add-ons are often too limited in expressive power. You are programming lisp in the backend, but all of a sudden you need to drop to a very dumb language when you need to deal with the template code, which is kind of frustrating. John Wiseman's code is very close to what I need, but it is designed to work with Franz's allegoserver. So I port it to work with my preferred web server (hunchentoot) instead. * So should I use this for all my dynamic content generation? No. Absolutely not. If you take a look at the very simple test.lsp, it screams like spaghetti code! In the ideal world, if the graphics designer can deliver properly formatted html in cl-who sexp, I'm all set. But that's not gonna happen. So for pages that I have total control, I prefer to write it using sexp. However, there are times where the designer need to frequently update a messy html template and I cannot afford to sync up with it given the time constraint, using lsp is a good compromise. * Any tips & tricks? Lisp is very hard to write (and even harder to read) without a good editor (like emacs) to help indenting your code and provide structured editing. So unlike other dumber languages (php, perl...), intermixed lisp code with content is extremely hard to maintain and read. In this regard, I would recommend you to use Franz's if-star package ( http://www.franz.com/~jkf/ifstar.txt ) in your template file because it helps you to match the open and close parenthesis for if-then-else conditional expression. Also, unlike other dumber languages where if you have a syntax error in the template file, the compiler can point you to the exact line where it occurs. With lsp, the line number is lost when we use the built-in lisp reader to read the form. However you can use `show-lsp-form' in the REPL to examine the code when you encounter an error.

3 2

[hunchentoot-devel] New release 0.11.0
by Edi Weitz 25 May '07

25 May '07

ChangeLog Version 0.11.0 2007-05-25 Added server names and coupled them with easy handlers (suggested by Mac Chan) Exported SESSION-COOKIE-VALUE instead of SESSION-STRING (suggested by Slava Akhmechet) Documentation fixes (thanks to Victor Kryukov and Igor Plekhov) Download http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi.

1 0

[hunchentoot-devel] (session-cookie-value) should be exported?
by Slava Akhmechet 25 May '07

25 May '07

I'm writing code to rewrite URLs in JavaScript to support AJAX requests for clients that have cookies disabled. It appears that the right thing to send would be the value returned by (session-cookie-value), not the value returned by the exported (session-string). Should 'session-cookie-value' be exported from the 'hunchentoot' package? -- Regards, Slava Akhmechet.

2 1

[hunchentoot-devel] Uploaded files are sometimes incomplete
by Viktor Leis 24 May '07

24 May '07

Hi, when using Hunchentoot with SBCL on debian behind mod_lisp and Apache 1 for video file uploading, the uploads randomly fail (the file is incomplete). Warning on the server: WARNING: 28369838 octets of stray data after form-data sent by client. This happens most of the time if the server is on the same machine as the uploading browser, less often if the server is on a different machine in the LAN and only sometimes if the upload goes through the internet. Using Apache2 seems to fix the problem. Any ideas what the problem may be? Thanks, Viktor

2 2

[hunchentoot-devel] [CL-WEBDAV] Property behaviour
by Ralf Mattes 24 May '07

24 May '07

Ok, i just had a closer look at the property code - too me it seems as if there's a lot of unnecessary redundance in the code. For example: A PROPGET for all properties of a resource will result in a call to 'collect-all-properties' that will call 'all-property-designators' which will result (at the end of a long call chain) in a call to 'get-dead-properties'. After that the same 'get-dead-properties' is called for each property again. Now, according to the documentation 'get-dead-properties' is supposed to return _all_ dead properties so it looks as if we do some extra work here ;-) Cheers, RalfD

2 4

[hunchentoot-devel] Re: Getting MD5
by Gary King 23 May '07

23 May '07

Hmm, It does now. I didn't this morning... sorry for overreacting! (and thanks) On May 23, 2007, at 12:29 PM, Kevin Rosenberg wrote: > Gary King wrote: >> I'm looking for MD5 source. Kevin Rosenberg's link is currently >> inaccessible (I've asked him too and I'm sure he'll fix it soon but >> I'm sometimes impatient! >smile<). > > Hi Gary, > > So http://files.b9.com/md5/ doesn't work for you? > > -- > Kevin Rosenberg > kevin(a)hypershots.com > -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM

1 0

[hunchentoot-devel] Getting MD5
by Gary King 23 May '07

23 May '07

Hi y'all, I'm looking for MD5 source. Kevin Rosenberg's link is currently inaccessible (I've asked him too and I'm sure he'll fix it soon but I'm sometimes impatient! >smile<). thanks, -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM

2 1

[hunchentoot-devel] Re: [flexi-streams-devel] Flexi-streams test suite failing on OpenMCL
by Edi Weitz 23 May '07

23 May '07

On Mon, 21 May 2007 21:32:45 +0100, "Tiarnan O'Corrain" <ocorrain(a)gmail.com> wrote: > The flexi-streams test suite is failing on OpenMCL "Version 1.0 > (DarwinPPC32)" on > > Test "hebrew_utf8_lf.txt" (:UTF-8 :EOL-STYLE :LF) [INPUT] > --> (:UTF-8 :EOL-STYLE :LF) [OUTPUT]. FWIW, I just borrowed my wife's iBook (PPC, OS X 10.3) for a couple of minutes and tried with OpenMCL Version 1.1 Prerelease 070512 (PPC-32). The test suite ran without problems for me. Could you check if it works for you as well? > I think this is also preventing Hunchentoot from working on recent > OpenMCL versions In the meantime, I've come to think this is another issue. I also had the problems others reported and the error message was something about some stream being "private" to some process. But I don't have enough time to dig into this, so if nobody steps up to resolve the issues with OpenMCL, I'll remove OpenMCL support from Hunchentoot for now.

3 5

[hunchentoot-devel] (Non)-Bug in subclassing dav:file-resource
by Ralf Mattes 23 May '07

23 May '07

Ok, I looked closer at the code for authorized-file-resource - I forgot to implement accept-request-p ... after fixing this everything works fine now. Thanks, RalfD

2 1

[hunchentoot-devel] problem on macosx with openmcl
by syamajala＠gamebox.net 23 May '07

23 May '07

Hello, I have been trying to get hunchentoot to work on mac os x with openmcl. It seems to load correctly and everything, but when I compile my program and try to access the page i get an error that says: Unknown http return code: 500 - Seshu

2 1

[hunchentoot-devel] Bugreport (and patch)
by Ralf Mattes 20 May '07

20 May '07

Hello, during some moderate WebDAV conformance tests is stumbled over the following bug/typo: --- handlers.lisp 2007-04-18 02:29:07.000000000 +0200 +++ /LISP/ediware/cl-webdav/handlers.lisp 2007-05-19 17:05:45.000000000 +0200 @@ -314,7 +314,7 @@ (let ((resource (get-resource))) (when (resource-exists resource) (setf (header-out :allow) - (format nil "~{~A~^~, ~}" + (format nil "~{~A~^, ~}" (set-difference *allowed-methods* '(:get :head :mkcol)))) (method-not-allowed)) (let ((parent (resource-parent resource))) MKCOL on an existing resource created an 500 status instead of the expected 405. Cheers, RalfD

2 3

[hunchentoot-devel] Logging with cronolog (hunchentoot behind mod_proxy)
by Andrei Stebakov 20 May '07

20 May '07

I am wondering if anyone is using cronolog with hunchentoot to split logging by year, month and day? I am using hunchentoot behind mod_proxy so can I rely on Apache's settings like CustomLog "|/usr/bin/cronolog /WebLogs/%Y/%m/%d-access.log".? I am just looking for some ideas how you split the log. Thank you, Andrew

1 0

[hunchentoot-devel] per server easy-handler-alist
by Mac Chan 18 May '07

18 May '07

Since Edit added the ultra-flexible macro define-easy-handler, I have replaced all my custom dispatch functions with it. There's a small issue with this macro, since it modifies the global *easy-handler-alist*. In production I have two server instances, one http and one https. I cannot easily say, for example, I want the following apply only to the https server instance. (define-easy-handler (home-page :uri "/login") () (with-html ...)) (define-easy-handler (home-page :uri "/my-account") () (with-html ...)) The problem is that start-server happens at run-time but define-easy-handler happens at load-time, so you cannot associate any server specific binding in define-easy-handler. Attached is a patch that introduce a slot :name to the server class and a global variable *servers* which is an a-list mapping names to server instances. With this you can do something like (define-easy-handler (home-page :uri "/hunchentoot/test/easy-home.html" :server-names '(:http)) () (with-html (:html (:body "Home page")))) (define-easy-handler (login-page :uri "/hunchentoot/test/easy-login.html" :server-names '(:https)) () (with-html (:html (:body "Secure login")))) (define-easy-handler (common-page :uri "/hunchentoot/test/easy-common.html" :server-names '(:https :http)) () (with-html (:html (:body "Common page")))) (start-server :name :http :port 8000) (stop-server :http) (start-server :name :https :port 4443) (stop-server :https) If you are not using multiple servers, this change will be transparent. I'd appreciate any suggestions. Regards, -- Mac

2 2

[hunchentoot-devel] ACL case sensitive reader incompatibilities
by Vyacheslav Akhmechet 16 May '07

16 May '07

I seem to run into some issues with Hunchentoot on ACL due to case sensitivity. When I turn case sensitivity off using '(set-case-mode :case-insensitive-upper)', everything behaves as expected. However, when I run in ACL's default mode, some things don't seem to work. Here is a list of issues I run into without the case-mode fix: 1. Loading Hunchentoot with asdf throws me into a debugger saying I need a newer version of TRIVIAL-GRAY-STREAMS. If I choose to continue at this point, I get another error in the debugger saying "Package :flexi-streams does not exist." When I choose an option to create it anyway, Hunchentoot loads fine. 2. (request-method) function returns symbols in the "incorrect" case - :GET and :POST, intead of :get and :post. This means it's not possible to simply compare symbols (using ecase, for example) - it becomes necessary to compare their names (with a case insensitive string comparison). Franz gives guidelines on how to write software that runs both on case sensitive and case insensitive implementations here: http://www.franz.com/support/documentation/5.0.1/doc/cl/case.htm. Are these being used by Hunchentoot? 3. Sessions/parameters don't seem to work properly. URL rewriting works, however it looks like the cookie functionality does not work. Additionally, (post-parameters) always returns nil on POST requests - effectively it's only possible to operate in GET mode. I'm not sure if Hunchentoot is meant to support ACL in its default reader mode, so I thought I'd report these issues. Regards, - Slava Akhmechet

2 1

[hunchentoot-devel] A typo in Hunchentoot doc?
by Victor Kryukov 16 May '07

16 May '07

Fourth paragraph of define-easy-handler documentation reads: The resulting handler will be a Lisp function with the name name and keyword parameters named by the var symbols. Each var will be bound to the value of the GET or POST parameter called real-name (a string) before the body of the function is executed. If real-name is not provided, it will be computed by downcasing the symbol name of name. It seems to me that last 'name' should be replace by 'var'. Regards, Victor. -- Yours Sincerely, Victor Kryukov

5 6

[hunchentoot-devel] *catch-errors-p* and spurious stream errors patch (add your own implementation and shake).
by Vladimir Sedach 11 May '07

11 May '07

Hello, While debugging a web application, the need to not catch errors became apparent. Unfortunately, there are spurious stream errors that make this less than useful currently (someone has informed me that this problem is well known). The attached patch is my proposal to let people deal with this and take advantage of (setf *catch-errors-p* nil). If you think this is the wrong way of going about things, please let me know. Thanks, Vladimir

3 6

[hunchentoot-devel] Can't write to FD-STREAM: Broken pipe
by Slava Akhmechet 11 May '07

11 May '07

I'm looking through the Hunchetoot log and occassionally I see the following messages: [2007-05-11 14:50:37 [ERROR]] Error while processing connection: couldn't write to #<SB-SYS:FD-STREAM for "a constant string" {BA242B1}>: Connection reset by peer [2007-05-11 14:50:37 [ERROR]] Error while processing connection: couldn't write to #<SB-SYS:FD-STREAM for "a constant string" {BDF02B1}>: Broken pipe I don't see any problems in the browser, I only found out about these messages because I looked at the log. Can someone think of a situation in which these errors would occur without interrupting user experience and why? -- Regards, Slava Akhmechet.

2 1

[hunchentoot-devel] HTTP PUT and DELETE
by Tiarnan O'Corrain 11 May '07

11 May '07

Hi-- does Hunchentoot support these, and if not, would it take much effort to implement them? Anyone else interested? regards Tiarnán

3 2

[hunchentoot-devel] Chunking disabled in ssl servers.
by Marco Monteiro 11 May '07

11 May '07

In the function START-SERVER, output chunking is explicitly disabled for SSL connections. Why? Is there any problem in using chunking with SSL? Marco

2 1