tbnl-devel February 2008

tbnl-devel@common-lisp.net

19 participants
11 discussions

[hunchentoot-devel] EQ used when comparing numbers [patch]
by Ariel Badichi 28 Feb '08

28 Feb '08

I found two places where EQ was used when comparing numbers. The following patch replaces each occurrence with EQL. Ariel --- headers.lisp~ 2008-02-13 18:02:17.000000000 +0200 +++ headers.lisp 2008-02-25 02:31:03.000000000 +0200 @@ -105,7 +105,7 @@ ;; is no content) (or chunkedp head-request-p - (eq (return-code) +http-not-modified+) + (eql (return-code) +http-not-modified+) (content-length) content))) ;; now set headers for keep-alive and chunking --- server.lisp~ 2008-02-13 18:02:18.000000000 +0200 +++ server.lisp 2008-02-25 02:31:16.000000000 +0200 @@ -420,7 +420,7 @@ backtrace))))) (with-debugger ;; skip dispatch if bad request - (when (eq (return-code) +http-ok+) + (when (eql (return-code) +http-ok+) ;; now do the work (dispatch-request *dispatch-table*))))) (when error

2 1

[hunchentoot-devel] Server sporadically hanging
by Jeff Cunningham 24 Feb '08

24 Feb '08

I am having a problem that I can't replicate on demand but has been happening with increasing frequency. I am hoping some of you might suggest ways to troubleshoot it. I don't know that it is a Hunchentoot problem, per se, but it may be an interaction problem between Hunchentoot and Apache2 via mod_lisp2. The symptom is the server is hung first thing in the morning when I check it. The cpu is at 99% activity on the server image (sbcl). When I look in the error_log I see dozens of these: [Wed Feb 20 05:10:10 2008] [error] (70007)The timeout specified has expired: error reading from Lisp [Wed Feb 20 05:12:23 2008] [error] (70007)The timeout specified has expired: error reading from Lisp [Wed Feb 20 05:15:14 2008] [error] (70007)The timeout specified has expired: error reading from Lisp [Wed Feb 20 05:18:57 2008] [error] (70007)The timeout specified has expired: error reading from Lisp These generally correspond to googlebot activity: 66.249.73.165 - - [20/Feb/2008:05:09:10 -0800] "GET /intrepid-obstacle-map.html?hunchentoot-session=18%3A15F2776FDB3BD7CA852EBF74A3B40B2B HTTP/1.1" 500 673 "-" "Mozilla/5.0 (c ompatible; Googlebot/2.1; +http://www.google.com/bot.html)" 66.249.73.165 - - [20/Feb/2008:05:11:23 -0800] "GET /index.html?hunchentoot-session=17%3A549FDE65186DCCFD1D2552AA79A49871 HTTP/1.1" 500 673 "-" "Mozilla/5.0 (compatible; Googl ebot/2.1; +http://www.google.com/bot.html)" 66.249.73.165 - - [20/Feb/2008:05:14:14 -0800] "GET /intrepid-obstacle-map.html?hunchentoot-session=17%3A549FDE65186DCCFD1D2552AA79A49871 HTTP/1.1" 500 673 "-" "Mozilla/5.0 (c ompatible; Googlebot/2.1; +http://www.google.com/bot.html)" 66.249.73.165 - - [20/Feb/2008:05:17:57 -0800] "GET /intrepid-robothon-2007.html?hunchentoot-session=15%3A3C06276A2A5CD0567B6A332AE52B3940 HTTP/1.1" 500 673 "-" "Mozilla/5.0 ( compatible; Googlebot/2.1; +http://www.google.com/bot.html)" And finally, netstat shows a whole bunch of 4242 ports open (these are just a small subset:) tcp 680 0 127.0.0.1:4242 127.0.0.1:38121 CLOSE_WAIT tcp 517 0 127.0.0.1:4242 127.0.0.1:44273 CLOSE_WAIT tcp 0 0 127.0.0.1:42641 127.0.0.1:4242 ESTABLISHED tcp 0 0 127.0.0.1:4242 127.0.0.1:51379 ESTABLISHED tcp 509 0 127.0.0.1:4242 127.0.0.1:33727 CLOSE_WAIT tcp 515 0 127.0.0.1:4242 127.0.0.1:44279 CLOSE_WAIT tcp 0 0 127.0.0.1:4242 127.0.0.1:48386 ESTABLISHED tcp 561 0 127.0.0.1:4242 127.0.0.1:44283 CLOSE_WAIT tcp 0 0 127.0.0.1:4242 127.0.0.1:42646 ESTABLISHED tcp 557 0 127.0.0.1:4242 127.0.0.1:43923 CLOSE_WAIT tcp 0 0 192.168.1.102:39210 192.168.1.2:993 ESTABLISHED tcp 0 0 127.0.0.1:42651 127.0.0.1:4242 ESTABLISHED tcp 0 0 127.0.0.1:4242 127.0.0.1:51382 ESTABLISHED tcp 589 0 127.0.0.1:4242 127.0.0.1:48377 CLOSE_WAIT tcp 589 0 127.0.0.1:4242 127.0.0.1:56928 CLOSE_WAIT tcp 589 0 127.0.0.1:4242 127.0.0.1:54195 CLOSE_WAIT The only way I can restart the server is to kill the process, restart it, and restart apache. Any ideas? Thanks. --Jeff

4 12

[hunchentoot-devel] Setting up hunchentoot, WARNING about thread support
by Berlin Brown 23 Feb '08

23 Feb '08

I am getting this message with hunchentoot, (most recent version as of today). WARNING: Without thread support, this library is only useful for development. My question, is this the normal mode of operation? Or do I really need thread support to do anything useful? Or were their flags I needed to setup on install. I am using SBCL 0.14 and I did the default install with that clisp. During the hunchentoot asdf-install, maybe there were options that I skipped over. This is ubuntu linux 7.10; (not using apt install for sbcl or hunchentoot) -- Berlin Brown http://botspiritcompany.com/botlist/spring/help/about.html

3 2

[hunchentoot-devel] Using javascript
by Lisp Newb 23 Feb '08

23 Feb '08

Apologies for an even newbier question, but here ( http://osdir.com/ml/lisp.lib.tbnl.general/2006-10/msg00063.html) I'm told I should put a js file in the root directory of my website and then use code like: (:html (:head (:link :href "myfile.css" :rel "stylesheet" :type "text/css") (:script :src "myfile.js" :type "text/javascript" nil) to access it. I installed hunchentoot via asdf. What's the root directory of my website? The directory containing the lisp file that calls start-server doesn't appear to be it.

3 3

[hunchentoot-devel] CCL/OpenMCL and WITH-TIMEOUT
by Hans Hübner 18 Feb '08

18 Feb '08

With the upcoming 1.2 release of CCL (formerly called OpenMCL), the old implementation of TIMER-REQUEST is no longer available. Hunchentoot relies on this in its WITH-TIMEOUT implementation which is (only) called from FORCE-OUTPUT*. As asynchronous timeouts are generally unsafe, I would like to get rid of WITH-TIMEOUT altogether. Instead, I think it would be better to only use the underlying streams' mechanisms for timeouts, if available. CCL 1.2 will have stream timeouts, LW already has them and the other Lisp implementations will propably support some form of timeouts in I/O sooner or later. Does anyone here have sentiments regarding WITH-TIMEOUT? If not, I'd propose that WITH-TIMEOUT be totally removed from Hunchentoot. -Hans

2 3

[hunchentoot-devel] Hunchentoot and SSL on cmucl
by Wout Perquin 17 Feb '08

17 Feb '08

Hi, I am struggling to get SSL working on cmucl. I looked at http://common-lisp.net/pipermail/tbnl-devel/2008-January/001616.html and did what was explained there : a) with openssl I generated private key and certificate b) I started the server with : (defvar *hportal443* (hunchentoot:start-server :port 443 :ssl-certificate-file #P"/data/lispdata/ssl/cacert.pem" :ssl-privatekey-file #P"/data/lispdata/ssl/pkey.pem")) When I browse to https://localhost then the browser notifies about the certificate. After I have accepted it, it takes about 25secs before the browser is done, however it renders an empty page. I expected to see the default page. Also any page I publish isnt rendered either. The log doesnt give any hints. It gives : [2008-02-17 11:28:39 [INFO]] Default handler called for script /favicon.ico [2008-02-17 11:28:39] 127.0.0.1 - "GET /favicon.ico HTTP/1.1" 200 641 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4" Is there anybody who had similar experiences and managed to get it sorted ? Thanks, Wout Perquin

4 5

[hunchentoot-devel] Finding out if we're multithreaded
by Vyacheslav Akhmechet 16 Feb '08

16 Feb '08

Hello, Is there an easy way to find out of Hunchentoot is using threads to handle requests? I'd like to issue a warning on single threaded systems, and I'm wondering if there is a unified way to get this information. Thanks, Slava Akhmechet

4 10

[hunchentoot-devel] handle-static-file patch
by Cyrus Harmon 13 Feb '08

13 Feb '08

Currently, if you use create-folder-dispatcher-and-handler to create a handler, it will call handle-static-file on a URL like http://bogushost.tld/this/is/a/directory and will give the contents of the directory as returned by fopen'ing the directory, which probably isn't what we want. The following patch to handle-static-file makes sure that the truename of the file has either a pathname-name or a pathname-type. Not sure if this is desired behavior or not, but I'd rather see a 500 error here. There's another error where if one sets up a folder- dispatcher-and-handler to catch "/www/foo/" and you request "/www/ foo/" you git an internal server error instead of a 500 error, but I haven't worked out the patch for that one yet. Thanks, Cyrus --- misc.lisp Thu Feb 7 18:46:24 2008 +++ misc-patched.lisp Thu Feb 7 18:46:01 2008 @@ -137,11 +137,12 @@ 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)) + (let ((true-path (truename path))) + (unless (or (pathname-name true-path) + (pathname-type true-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+)

3 5

[hunchentoot-devel] parameters
by Rommel Martinez 12 Feb '08

12 Feb '08

Hi! How do I make an HREF link "call" a dispatch function (and "pass" parameters without having to write long strings like this: "/?foo=1&bar=2&baz=3" I am able to do it with forms, using POST, but not with HREFs. :-( Sorry, I'm new to Hunchentoot. Please bear with me. Thanks. :-) -- Rommel M. Martinez <ebzzry(a)gmail.com>

2 2

[hunchentoot-devel] Hunchentoot Thread Safety
by Mostafa Razavi 07 Feb '08

07 Feb '08

Hi. I've been thinking about Hunchentoot's thread safety, lately. I see that for each request Hunchentoot spawns a new thread (if possible, of course) and binds the special variable *request* for it. Initially I thought this could cause problems, but when I did a few tests I found out everything actually seems to work correctly. Now, I'm not complaining why things are not going wrong, only I'm curious how is it that using a dynamic variable, which is one of those dreaded global variables after all, does not cause problems here. You might point out I can find it out all by myself by reading the source code, but unfortunately I couldn't. Maybe I'm missing something. Can anyone here, please, point me to the answer? Thanks. Hom

7 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel February 2008