tbnl-devel May 2008

tbnl-devel@common-lisp.net

23 participants
18 discussions

[hunchentoot-devel] Current development
by Edi Weitz 14 Jun '08

14 Jun '08

As common-lisp.net has been pretty unreliable in the last days, we've moved development over to the bknr.net server maintained by Hans. If you're interested in trying out the soon-to-be-released Hunchentoot version, get all of Hunchentoot, Chunga, and FLEXI-STREAMS from here: http://bknr.net/trac/browser/trunk/thirdparty If you're using Drakma, you'll have to grab it from bknr.net as well, as there are incompatible changes in Chunga. The previous development history can be seen at http://trac.common-lisp.net/tbnl/browser/branches whenever the server is up. Edi.

9 29

[hunchentoot-devel] hunchentoot-error error
by Cyrus Harmon 01 Jun '08

01 Jun '08

conditions.lisp has two definitions of hunchentoot-error, and none for hunchentoot-warn. the following patch fixes this: Index: conditions.lisp =================================================================== --- conditions.lisp (revision 3232) +++ conditions.lisp (working copy) @@ -1,5 +1,5 @@ -;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: ODD-STREAMS; Base: 10 -*- -;;; $Header: /usr/local/cvsrep/odd-streams/conditions.lisp,v 1.5 2007/12/31 01:08:45 edi Exp $ +;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10 -*- +;;; $Header: /usr/local/cvsrep/hunchentoot/conditions.lisp,v 1.5 2007/12/31 01:08:45 edi Exp $ ;;; Copyright (c) 2008, Dr. Edmund Weitz. All rights reserved. @@ -56,7 +56,7 @@ () (:documentation "Like HUNCHENTOOT-WARNING but with formatting capabilities.")) -(defun hunchentoot-error (format-control &rest format-arguments) +(defun hunchentoot-warn (format-control &rest format-arguments) "Signals a warning of type HUNCHENTOOT-SIMPLE-WARNING with the provided format control and arguments." (warn 'hunchentoot-simple-warning

2 1

[hunchentoot-devel] New release 0.15.7 (and also FLEXI-STREAMS 0.15.0)
by Edi Weitz 31 May '08

31 May '08

This is a tiny change which should improve Hunchentoot's performance. Incidentally, if you're concerned about performance, you might consider giving FLEXI-STREAMS 0.15.0 a try which was also released today. http://weitz.de/files/hunchentoot.tar.gz http://weitz.de/files/flexi-streams.tar.gz I'd also recommend to everyone interested in Hunchentoot's future directions to check out Hans' current version from here http://trac.common-lisp.net/tbnl/browser/branches/hans and to play with it. This version needs an updated Chunga (at least 0.4.2): http://weitz.de/files/chunga.tar.gz Edi.

2 1

[hunchentoot-devel] conditional reader error
by Cyrus Harmon 31 May '08

31 May '08

In hunchentoot.asd, I think the #+(not foo bar ...) bit is wrong: Index: hunchentoot.asd =================================================================== --- hunchentoot.asd (revision 3230) +++ hunchentoot.asd (working copy) @@ -76,7 +76,7 @@ #+(and :lispworks :unix) (:file "unix-lw") #+(and :openmcl :unix) (:file "unix-mcl") #+(and :sbcl :unix (not :win32)) (:file "unix-sbcl") - #+(and (not :allegro :clisp :cmu :lispworks :openmcl :sbcl) :unix) (:file "unix-other") + #+(and (not (or :allegro :clisp :cmu :lispworks :openmcl :sbcl)) :unix) (:file "unix-other") (:file "set-timeouts") (:file "connection-manager") (:file "server")

2 1

[hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports
by Raditya Kertiyasa 30 May '08

30 May '08

Hi everbody, I'm a Lisp newbie but I need to get my system up and running fast. I'm building a system that might cause multiple Hunchentoot servers to use conflicting ports. I want to handle this with an error handler and I've setup a wrapper function to start Hunchentoot and a restart function: ;; restart function to handle conflicting ports (defun ht-port-conflict-handler (condition) (... do something here to address the conflicting ports ...) (invoke-restart 'ht-port-conflict-handler)) ;; Start Hunchentoot Server with error-handling (defun ht-start-with-error-handler () (handler-bind ((simple-error #'ht-port-conflict-handler)) (restart-case (setf *ht-handle* (hunchentoot:start-server :port *ht-port*)) (ht-port-conflict-handler () nil)))) The system should allow users to reconfigure their instance of Hunchentoot without having to invoke the debugger, but when I run this code I always end up in the debugger anyway. Can anybody tell me where I went wrong? Or maybe there's a better solution for my situation? Regards, Raditya Kertiyasa

3 11

[hunchentoot-devel] as-keyword and other utility functions
by Cyrus Harmon 30 May '08

30 May '08

I see that in some of my code I was relying on hunchentoot::make- keyword, which has now gone away. But there is as-keyword and there is chunga::make-keyword. And there's, of course, alexandria:make-keyword, if I want to use that. It's a trivial function, but would it make sense to take things like with-unique-names, make-keyword, etc... and put it in some sort of ediware-utilities package? It's a trivial issue in this case, but I figured I'd bring it up for handy and less-trivial things like with-rebinding, etc... thanks, Cyrus

2 3

[hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread
by css 29 May '08

29 May '08

Hello. My problem may seem strange, but: I have a huge download to generate on my hunchentoot, and I dont want to have one thread for each of these downloads, but one thread answering multiple requests at the same time (since the generation takes time, caching takes space, and sending the generated code to multiple receivers seems the best idea to me). That is, I want to get the request-object, and then pass it to another thread, who is then handling multiple requests (i.e. sending "non-waiting", polling for input, etc.). Is this possible?

5 12

[hunchentoot-devel] Encoding issues in auhtorization header
by Christian Haselbach 22 May '08

22 May '08

Hello, I just stumbled upon an encoding problem with the authorization header. It cannot really handle UTF-8 encoded user names (or passwords), because base64:base64-string-to-string does not respect the used encoding. In my local instance, I fixed this by changing hunchentoot's authorization function as follows: (defun authorization (&optional (request *request*)) "Returns as two values the user and password \(if any) as encoded in the 'AUTHORIZATION' header. Returns NIL if there is no such header." (let* ((authorization (header-in :authorization request)) (start (and authorization (> (length authorization) 5) (string-equal "Basic" authorization :end2 5) (scan "\\S" authorization :start 5)))) (when start (let* ((auth-octets (base64:base64-string-to-usb8-array (subseq authorization start))) (auth (octets-to-string auth-octets :external-format *hunchentoot-default-external-format*))) (destructuring-bind (&optional user password) (split ":" auth) (values user password)))))) Or as patch: 286,288c286,293 < (destructuring-bind (&optional user password) < (split ":" (base64:base64-string-to-string (subseq authorization start))) < (values user password))))) --- > (let* ((auth-octets (base64:base64-string-to-usb8-array > (subseq authorization start))) > (auth (octets-to-string auth-octets > :external-format > *hunchentoot-default-external-format*))) > (destructuring-bind (&optional user password) > (split ":" auth) > (values user password)))))) Regards, Christian

3 9

Re: [hunchentoot-devel] hunchentoot + nginx
by Anton Vodonosov 22 May '08

22 May '08

Hi, Nick. I'm using hunchentoot behind nginx, but not to say I've learned any lessons. It works (why not?). Good luck, -Anton 19.05.08, 19:41, "Nick Allen" : >is anyone out there using hunchentoot behind nginx? > >if so would they be willing to post any pointers / experiences / lessons learned / reasons not to? > >take care > >Nick

2 1

[hunchentoot-devel] hunchentoot + nginx
by Nick Allen 19 May '08

19 May '08

is anyone out there using hunchentoot behind nginx? if so would they be willing to post any pointers / experiences / lessons learned / reasons not to? take care Nick

1 0

None
by None 15 May '08

15 May '08

1 0

[hunchentoot-devel] [PATCH] Hunchentoot must depends on FLEXI-STREAMS
by Luca Capello 15 May '08

15 May '08

Hi there! Please Cc: me, I'm not subscribed to the list and I'm posting from Gmane. Moreover, please ignore this message if it has been already answered, but I cannot find any reference of it. Working on the Debian package for Hunchentoot, if I'm correct I found that while Hunchentoot depends on FLEXI-STREAMS, this dependency is present in the packages.lisp file but not in the ASDF one. This dependency, however, is implicitly satisfied in all CLs but LispWorks: in fact, CL+SSL (required unless on LispWorks) depends on FLEXI-STREAMS. From a quick view, I guess that if you want to use Hunchentoot without SSL support this will miss the FLEXI-STREAMS dependency as well. The following patch unconditionally adds the dependency to FLEXI-STREAMS and it's untested since I don't have LispWorks. --8<---------------cut here---------------start------------->8--- --- hunchentoot-0.15.6.ORIG/hunchentoot.asd 2008-04-09 10:17:48.000000000 +0200 +++ hunchentoot-0.15.6/hunchentoot.asd 2008-05-15 00:05:49.000000000 +0200 @@ -48,6 +48,7 @@ :cl-fad :cl-ppcre #-(or :lispworks :hunchentoot-no-ssl) :cl+ssl + :flexi-streams :md5 :rfc2388 #+:sbcl :sb-bsd-sockets --8<---------------cut here---------------end--------------->8--- Comments? Thx, bye, Gismo / Luca

2 1

[hunchentoot-devel] usocket patch and ecl smallcons
by Geo Carncross 14 May '08

14 May '08

I haven't heard anything back about ecl and hunchentoot. Did I send it to the right place? I've started testing ECL's new smallcons support, and it needed patching usocket further; I haven't seen your svn repository accept the patch yet, so I'm submitting it again -this time with smallcons support. I've also included the relevant patches at: http://geocar.googlepages.com/usocket-ecl-2.diff I notice the hans svn of hunchentoot still doesn't build when :HUNCHENTOOT-NO-SSL is in effect. http://geocar.googlepages.com/hunch-nossl-2.patch fixes it. I also supplied a patch to support backtraces on ecl: http://geocar.googlepages.com/hunch-ecl-backtrace.patch Let me know if there's anything else I need to do.

2 1

[hunchentoot-devel] How to use Sessions ?
by Thibault Langlois 14 May '08

14 May '08

Hello, Maybe someone can show me the light. I am trying to use hunchentoot's session feature but whenever (start-session) is called I get this error on the log: A function with declared result type NIL returned: MD5:UPDATE-MD5-BLOCK. Any ideas ? This is my first attempt to use session maybe I am missing something obvious. I am using huchentoot (0.15.6) chunga (0.3.0) cl-base64 (3.3.2) cl-fad (0.6.2) and flexi-streams (0.14.0) with sbcl 1.0.9. Thibault

3 5

[hunchentoot-devel] Strange condition during error handling (possible double error?)
by Tomasz Skutnik 11 May '08

11 May '08

Hi. For my development I've tried to setup hunchentoot error logging/condition handling that better suits taste. Here's my setup (code snippets to reduce word clutter): (setf hunchentoot:*catch-errors-p* nil hunchentoot::*log-lisp-backtraces-p* t hunchentoot::*log-lisp-errors-p* t hunchentoot::*log-lisp-warnings-p* t hunchentoot::*show-lisp-errors-p* t hunchentoot::*show-lisp-backtraces-p* t) (defgeneric maybe-log-condition (condition) (:documentation "This generic function is called whenever a condition CONDITION is about to be logged in an application. You might want to specialize it on specific condition classes to fine-tune error and warning logging in addition to Hunchentoot's *log-lisp-errors-p* and *log-lisp-warnings-p*.") (:method (condition) t)) (defmethod log-message :around (log-level fmt &rest args) (let ((*log-level* log-level) (*fmt* fmt) (condition (and args (car args)))) (declare (special *log-level* *fmt*)) (cond ((and condition (typep condition 'condition)) (when (maybe-log-condition condition) (call-next-method))) (t (call-next-method))))) (defmethod maybe-invoke-debugger ((condition sb-int:simple-stream-error)) ; muffle useless condition reporting (cond ((eql (search "/img/" (script-name *request*)) 0) (log-message :warn "ignored condition for ~a: ~a" (script-name *request*) condition)) (t (call-next-method)))) (defmethod maybe-log-condition ((condition sb-int:simple-stream-error)) nil) It's rather crude workaround for something that should probably be more tightly integrated into hunchentoot (customizable error/warning logging similar to maybe-invoke-debugger). Notice maybe-invoke-debugger specialized for sb-int:simple-stream-error. I've put that in my development setup because I've tried to silence Firefox related errors, which has nasty habit of dropping connection on favicon.ico retrieval (well, that's what I suspect; haven't check that theory with packet sniffer) that results in "Broken pipe" condition. So far all fine and dandy. But, for every such condition handled by my code hunchentoot logs following line: [2008-05-10 11:41:42 [ERROR]] Error while processing connection: The variable *REQUEST* is unbound. No more information available. So I've modified hunchentoot a little bit: diff -x '*.fasl' -r -u -w -B hunchentoot-0.15.6.orig/server.lisp hunchentoot-0.15.6/server.lisp --- hunchentoot-0.15.6.orig/server.lisp 2008-04-09 10:17:48.000000000 +0200 +++ hunchentoot-0.15.6/server.lisp 2008-04-21 22:25:33.000000000 +0200 @@ -282,6 +282,7 @@ (lambda (cond) (log-message *lisp-errors-log-level* "Error while processing connection: ~A" cond) + (log-message *lisp-errors-log-level* "~a" (get-backtrace cond)) (return-from process-connection))) (warning ;; log all warnings which aren't caught inside and got following: [2008-05-10 11:41:42 [ERROR]] Error while processing connection: The variable *REQUEST* is unbound. [2008-05-10 11:41:43 [ERROR]] 0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {AF6C86D}>)[:EXTERNAL] 1: (SB-DEBUG:BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {AF6C809}>) 2: (GET-BACKTRACE #<unused argument>) 3: ((LAMBDA (COND)) #<UNBOUND-VARIABLE *REQUEST* {A793961}>) 4: ((LAMBDA (COND)) #<UNBOUND-VARIABLE *REQUEST* {A793961}>)[:EXTERNAL] 5: (SIGNAL #<UNBOUND-VARIABLE *REQUEST* {A793961}>)[:EXTERNAL] 6: (ERROR UNBOUND-VARIABLE)[:EXTERNAL] 7: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB51C1DF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB51C1A7C :TYPE (* (SB-ALIEN:STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14)) 8: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB51C1DF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB51C1A7C :TYPE (* (SB-ALIEN:STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EXTERNAL] 9: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB51C1A7C) #<unavailable argument>) 10: ("foreign function: call_into_lisp") 11: ("foreign function: funcall2") 12: ("foreign function: interrupt_internal_error") 13: ("foreign function: handle_trap") 14: ((SB-PCL::FAST-METHOD MAYBE-INVOKE-DEBUGGER (SB-INT:SIMPLE-STREAM-ERROR)) #<unused argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1)) #<SB-INT:SIMPLE-STREAM-ERROR {A78E219}>) 15: (SIGNAL #<SB-INT:SIMPLE-STREAM-ERROR {A78E219}>)[:EXTERNAL] 16: (ERROR SB-INT:SIMPLE-STREAM-ERROR)[:EXTERNAL] 17: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s" #<SB-SYS:FD-STREAM for "a socket" {B123609}> 32) 18: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s" #<SB-SYS:FD-STREAM for "a socket" {B123609}> 32)[:EXTERNAL] 19: (FORCE-OUTPUT #<SB-SYS:FD-STREAM for "a socket" {B123609}>) 20: ((SB-PCL::FAST-METHOD SB-GRAY:STREAM-FORCE-OUTPUT (CHUNGA:CHUNKED-OUTPUT-STREAM)) #<unused argument> #<unused argument> #<CHUNGA:CHUNKED-IO-STREAM {B127C49}>) 21: (FORCE-OUTPUT #<CHUNGA:CHUNKED-IO-STREAM {B127C49}>) 22: (FORCE-OUTPUT #<FLEXI-STREAMS::FLEXI-UTF-8-IO-STREAM {B12A4E9}>) 23: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER {B3C6FB1}> #<SB-BSD-SOCKETS:INET-SOCKET descriptor 11 {B121819}>) 24: ((LAMBDA ())) 25: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 26: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]438)) 27: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B51C2295}> #S(SB-THREAD:MUTEX :NAME "thread result lock" :%OWNER #<SB-THREAD:THREAD "hunchentoot-worker-2" {B1225D9}> :STATE 1) #<SB-THREAD:THREAD "hunchentoot-worker-2" {B1225D9}> T) 28: ((LAMBDA ())) 29: ("foreign function: call_into_lisp") 30: ("foreign function: funcall0") 31: ("foreign function: new_thread_trampoline") 32: ("foreign function: #xB7FD2240") Looking at the above backtrace and process-connection source code I wasn't able to figure out anything constructive. I'm stuck. It looks for me like double error (error during error handling), but what do I know? Can someone tell me what am I doing wrong? Can I avoid this "The variable *REQUEST* is unbound." error? Is this hunchentoot error or my silly mistake? Take into account that these are my first 40 or so hours with CL (not even mentioning Hunchentoot). I'm using SBCL 1.0.15 and Hunchentoot 0.15.6. Thanks Tomasz

2 2

[hunchentoot-devel] error computing the request object
by Sergio Garcia 09 May '08

09 May '08

Hello, Im using utf-u as the default external format in my web application (yet another social news site). Some sites have started to add links to our site, passing the title of their news as a GET parameter in the link. The problem is that one of those sites is encoding the title string using iso-8859 encoding, which causes hunchentoot to return a "Your browser sent a request that this server could not understand." and a log error that looks like "Error when creating REQUEST object: Unexpected value #x20 in UTF-8 sequence.". Is there a way I can catch the error so that I can either to ignore the parameters or try to recompute the REQUEST object using iso-8859 encoding? Thanks Sergio

2 3

[hunchentoot-devel] hunchentoot ecl support
by Geo Carncross 08 May '08

08 May '08

Hi, I've successfully gotten hunchentoot to run under ECL. I'm attaching a port-ecl.lisp which implements the necessary machinery for hunchentoot. In case you have trouble reading the attachment, I've also uploaded it to: http://geocar.googlepages.com/port-ecl.lisp Note, this has required patches to ECL and TRIVIAL-GRAY-STREAMS. The relevent patches are already checked into ECL's CVS. The FLEXI-STREAMS patches, and other patches at: http://nasobem.i-networx.de/hunchentoot-patches/ that were brought up in the thread at: http://common-lisp.net/pipermail/tbnl-devel/2008-March/001789.html are *not* required. The gray streams infrastructure (among other things) has been reworked very recently in ECL which has made this patch very straightforward. So far, I've gotten a few test pages to show up, but would like to know how I can get support included into hunchentoot.

2 2

[hunchentoot-devel] Newbie question - how to examine session object?
by Yarek Kowalik 06 May '08

06 May '08

I'm a lisp newbie, but I am very determined to quickly learn it. I'm using most recent SBCL with Weblocks. I'm connecting to my SBCL using slime. I'm intrested in examining the ession objects - what's the most effective way of examining the session object? Here is what I have tried, but obviously I am doing something wrong: ------------------- CL-USER> (weblocks:active-sessions) (#<HUNCHENTOOT::SESSION {100245E011}>) CL-USER> (hunchentoot:session-value :remote-addr (#<HUNCHENTOOT::SESSION {100245E011}>) ) ; in: LAMBDA NIL ; (#<HUNCHENTOOT::SESSION {100245E011}>) ; ; caught ERROR: ; illegal function call ; ; compilation unit finished ; caught 1 ERROR condition ------------------- ... at which point I get into the debugger... What am I doing wrong? Any help would be greatly appreciated. Thanks, Yarek

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel May 2008