January 2008 - tbnl-devel@common-lisp.net

[hunchentoot-devel] hunchentoot CGI?
by Cyrus Harmon 01 Feb '08

01 Feb '08

This may seem counterproductive but has anyone used Hunchentoot for running CGI scripts? It seems like this should be pretty straightforward, but I could be missing something. Thanks, Cyrus

2 2

[hunchentoot-devel] Does hunchentoot close the stream returned by SEND-HEADERS?
by Chaitanya Gupta 31 Jan '08

31 Jan '08

Or should it be closed explicitly by the app? Thanks, Chaitanya

2 2

Re: [hunchentoot-devel] Does hunchentoot close the streamreturnedby SEND-HEADERS?
by Cunningham, Jeff 29 Jan '08

29 Jan '08

Edi Weitz wrote: > On Tue, 29 Jan 2008 12:43:54 -0800, "Cunningham, Jeff" <jeffrey.k.cunningham(a)boeing.com> wrote: > > >> I use drakma regularly to examine what is happening on several >> Hunchentoot sites and Hunchentoot always seems to take care of >> closing the streams properly. >> > > Have you ever checked if it also takes care of /not/ closing the > stream if you use Drakma with something like :CLOSE NIL so that you > can re-use the stream? > > Thanks, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > No, I haven't. I'll see if I can give it a try here in the next day. --Jeff

1 0

Re: [hunchentoot-devel] Does hunchentoot close the stream returnedby SEND-HEADERS?
by Cunningham, Jeff 29 Jan '08

29 Jan '08

Edi Weitz wrote: > On Tue, 29 Jan 2008 23:07:46 +0530, Chaitanya Gupta <mail(a)chaitanyagupta.com> wrote: > > >> Or should it be closed explicitly by the app? >> > > Handlers should definitely /not/ close the stream themselves. > Hunchentoot is supposed to do the right thing depending on the headers > sent back and forth between the client and the server - sometimes it > will close the stream, sometimes it won't. You can check with Drakma > (for example) if that really happens, but I think it does. > > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > I use drakma regularly to examine what is happening on several Hunchentoot sites and Hunchentoot always seems to take care of closing the streams properly. Jeff

2 1

[hunchentoot-devel] OpenMCL and corrupted multipart/form-data posted binary files
by Peter Eddy 21 Jan '08

21 Jan '08

Hi, I noticed today that binary files uploaded to my web app running in Hunchentoot were being corrupted (though text files look fine.) So I tried the hunchentoot test code and found it had the same problem with binary files. This is on OSX (Leopard), Intel 64 bit. I then tried the same hunchentoot test app on a Linux intel 32 bit platform with SBCL and saw similar corruption. However after updating hunchentoot and flexi-streams and maybe other packages (I just did an asdf-install of hunchentoot to get any new stuff, then removed all existing fasls) the corruption went away. Unfortunately updating packages and removing fasls didn't fix the problem on the Mac. Is this a known problem? On both systems I'm using: hunchentoot-0.15.0 flexi-streams-0.14.0 trivial-gray-streams-2006-09-16 chunga-0.4.1 OpenMCL is the 2007-07-22 release SBCL is version 1.0.13-1 thanks, Peter

2 2

[hunchentoot-devel] Ways to work with case sensitive lisps...
by Gary King 20 Jan '08

20 Jan '08

I was just trying to work with Hunchentoot and Allegro MoDeRn lisp and it's not fun. Sensibly enough, both Chunga and Hunchentoot convert headers and such coming from the web into assoc lists with keywords as keys. However, the keywords are created by upcasing the strings and interning them and in MoDeRn lisp, :HOST does not eq :host and this leaves much of the hander code confused. I'm considering either altering make-keyword or switching the test to be case insensitive but I'm concerned that I may miss places that matter. Is anyone bumping into this? regards, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM

1 0

[hunchentoot-devel] session shearing question
by Andrea Chiumenti 18 Jan '08

18 Jan '08

Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it?

8 31

Re: [hunchentoot-devel] hunchentoot and virtual hosts.
by Nicolas Lamirault 11 Jan '08

11 Jan '08

> Edi Weitz <edi(a)agharta.de> writes: > >> On Tue, 08 Jan 2008 17:21:13 +0100, Nicolas Lamirault <nlamirault(a)gmail.com> wrote: >> >>> i modify the Apache configuration file : >>> >>> <VirtualHost *:80> >>> ServerName www.myfoo.org >>> LispServer 127.0.0.1 9090 "ProdFoo" >>> SetHandler lisp-handler >>> </VirtualHost> >>> >>> but if i try www.myfoo.org i've got an error 500 >> >> A 500 error is usually a sign that mod_lisp couldn't connect to the >> Lisp process. Did you try a full restart of Apache (shut down, then >> start up again)? Sometimes mod_lisp leaves "old" sockets open if you >> only do a "graceful" restart. ok >> Is your Lisp process really listening on 9090? Have you confirmed >> that your web application works correctly if you connect to it >> directly, i.e. if you start it without :MOD-LISP-P T? yes. My site works fine with Hunchentoot without modlisp. I would like to make differents virtuals instead of differents port (8888 for dev, 8989 for test and 9090 for prod). >> I think the docs somewhere say that working with mod_lisp is more >> inconvenient than working without it. One of the reasons is that you >> might have to restart Apache pretty often. Another one is that >> debugging is harder. I would recommend to develop your app >> "stand-alone" and only if it works switch it to mod_lisp. i did that :) i'm just trying to switch to hunchentoot+mod_lisp i think the problems comes from Apache configuration. I start my web site in 'prod environment. - without mod_lisp it works fine : http://localhost:9090/index -> Http code 200, and home page correct - with mod_lisp doesn't work The Apache configuration : <VirtualHost *:80> ServerName dev.foo.org ServerAdmin webmaster-dev(a)foo.org ErrorLog /var/log/apache/dev.foo.org-error_log CustomLog /var/log/apache/dev.foo.org-access_log common LispServer 127.0.0.1 8888 "DevOvorost" SetHandler lisp-handler </VirtualHost> <VirtualHost *:80> ServerName test.foo.org ServerAdmin webmaster-test(a)foo.org ErrorLog /var/log/apache/test.foo.org-error_log CustomLog /var/log/apache/test.foo.org-access_log common LispServer 127.0.0.1 8989 "TestOvorost" SetHandler lisp-handler </VirtualHost> <VirtualHost *:80> ServerName www.foo.org ServerAdmin webmaster(a)foo.org ErrorLog /var/log/apache/foo.org-error_log CustomLog /var/log/apache/foo.org-access_log common LispServer 127.0.0.1 9090 "ProdOvorost" SetHandler lisp-handler </VirtualHost> http://www.foo.org/index http://localhost/index -> http error 500 -- Nicolas Lamirault

2 2

[hunchentoot-devel] Hunchentoot performance
by vseguip＠gmail.com 11 Jan '08

11 Jan '08

Hi all, First, as a disclaimer, I'm a total Lisp noobie and have been playing with it recently poking here and there. I just tried Hunchentoot and was happy to see how easy it is to use. I also tried to make some preformance benchmarks on static files and compared it with lighttpd. Unsurprisingly lighttpd beat Hunchentoot quite badly, but I see there is still a lot of improvement for hunchentoot. I did some profiling and added a specialized handler that would serve static files using the linux sendfile system call which really improved the performance. Anyway I still see plenty room for improvements and I would like to take a stab at it, so I did some profiling. I'm putting the results in the ML in case someone wants to discuss it and help me figure out whether the speed for this use case can be improved. Details about the benchmark setup follow: Intel Dual Core 2 2.0 GHz 1 Gb Ram Ubuntu Gutsy 7.10 SBCL version: Hunchentoot version: Lighttpd version: Benchmark program: ab File: 10 mb bitmap Command: ab -n 1000 -c 20 -k http://127.0.0.1/sendfile/1.jpg Using sendfile system call | consed | calls | sec/call | name ----------------------------------------------------------- 0.644 | 25,410,696 | 1,002 | 0.000643 | HUNCHENTOOT::GET-REQUEST-DATA 0.453 | 197,900,328 | 6,006 | 0.000075 | HUNCHENTOOT::WRITE-HEADER-LINE 0.435 | 19,617,768 | 1,001 | 0.000435 | HUNCHENTOOT::HANDLE-STATIC-SENDFILE 0.367 | 0 | 1,001 | 0.000367 | HUNCHENTOOT::SENDTHEFILE 0.230 | 53,605,640 | 1,001 | 0.000230 | HUNCHENTOOT:LOG-MESSAGE 0.163 | 36,415,056 | 2,002 | 0.000082 | HUNCHENTOOT::START-OUTPUT ... Using hunchentoot static folder dispatcher | consed | calls | sec/call | name ----------------------------------------------------------- 0.678 | 165,618,816 | 5,000 | 0.000136 | HUNCHENTOOT::WRITE-HEADER-LINE 0.556 | 27,725,384 | 1,000 | 0.000556 | HUNCHENTOOT::GET-REQUEST-DATA 0.347 | 45,721,424 | 1,000 | 0.000347 | HUNCHENTOOT::START-OUTPUT 0.266 | 57,833,952 | 1,000 | 0.000266 | HUNCHENTOOT:LOG-MESSAGE 0.247 | 20,982,224 | 1,000 | 0.000247 | HUNCHENTOOT::COMPUTE-LENGTH 0.135 | 12,926,840 | 2,000 | 0.000067 | HUNCHENTOOT::FORMAT-ADDRESS 0.115 | 13,878,936 | 1,000 | 0.000115 | HUNCHENTOOT::ISO-TIME 0.082 | 237,656 | 1,000 | 0.000082 | HUNCHENTOOT::MAKE-SOCKET-STREAM 0.079 | 16,425,808 | 1,000 | 0.000079 | HUNCHENTOOT:RFC-1123-DATE .... This is my very dirty implementation of the dispatcher function which is shameles rip of hunchentoot's with some minor functions cleaned : (declaim (inline sendfile)) (define-alien-routine "sendfile" int (out_fd int :in) (in_fd int :in) (offset unsigned-long :in-out) (count unsigned-long :in)) (in-package :hunchentoot) (defun handle-static-sendfile (path &optional content-type) "A function which acts like a Hunchentoot handler for the file denoted by PATH but uses the sendfile call. 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)) (setf (content-type) (or content-type (mime-type path) "application/octet-stream")) (with-open-file (file path :direction :input :element-type '(unsigned-byte 8) :if-does-not-exist nil) (setf (content-length) (file-length file)) (let ((out (chunga:chunked-stream-stream (flex:flexi-stream-stream *hunchentoot-stream*))) (in (sb-sys:fd-stream-fd file))) (send-headers) (force-output out) (sendthefile (sb-sys:fd-stream-fd out) in 0 (content-length))))) (defun sendthefile (out in off size) (common-lisp-user::sendfile out in off size)) Just for reference, the sendfile dispatcher does some 350 req/s wherea hunchentoots does about 228 req/s on my machine and against 1199.41 req/s that lighttps can serve using the sendfile backend (data for a 993Kb jpg file with 20 concurrency level). Thanks for your time, V. Seguí

8 22

[hunchentoot-devel] hunchentoot and virtual hosts.
by Nicolas Lamirault 08 Jan '08

08 Jan '08

hello. I've got a web project which have differents environment : dev, test and prod. i've got 3 web site : http://localhost:8888, http://localhost:8989, and http://localhost:9090 for theses environments. i would like to make 3 virtual hosts using apache+modlisp+hunchentoot i modify httpd.conf life this : <VirtualHost *:80> ServerName dev.myfoo.org LispServer 127.0.0.1 8888 "DevFoo" SetHandler lisp-handler </VirtualHost> <VirtualHost *:80> ServerName test.myfoo.org LispServer 127.0.0.1 8989 "TestFoo" SetHandler lisp-handler </VirtualHost> <VirtualHost *:80> ServerName myfoo.org LispServer 127.0.0.1 9090 "ProdFoo" SetHandler lisp-handler </VirtualHost> <VirtualHost _default_:80> DocumentRoot /var/www/ </VirtualHost> i start the PROD web site with : hunchentoot:start-server :port 9090 :mod-lisp-p t i try http://www.myfoo.org, but i've got not response. anyone understand where is my mistake on this configuration ? thanks for any help -- Nicolas Lamirault

3 6