From jeffrey at cunningham.net Wed Jul 2 15:29:35 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Wed, 02 Jul 2008 08:29:35 -0700 Subject: [hunchentoot-devel] googlebot revisitation rate excessive? In-Reply-To: References: <48681B63.40407@cunningham.net> <20080629233317.GB14673@xach.com> <48682242.4010205@cunningham.net> <20080630000448.GD14673@xach.com> <486825A2.9060402@cunningham.net> Message-ID: <486B9EDF.9090905@cunningham.net> Hans H?bner wrote: > I'd set HUNCHENTOOT:*HEADER-STREAM* to *STANDARD-OUTPUT* and > *BREAK-ON-SIGNALS* to 'WARNING, then wait for the Googlebot request to > come in. The headers printed to the console may give you a clue what > the request looks like and maybe a way to initiate such a failing > request yourself, maybe with Drakma or wget. You'll may also be able > to get a clue from looking at the backtrace in a debugger. > > Good suggestion, Hans. I found a contraction inside a meta content string which was demarked with single quotes. > I find it curious that Google retries every five minutes. Did you > verify that the request is coming from a Google IP address? It may > also be a prankster's script gone wild, in which case I'd block the IP > address. > It is curious. I'd checked it right off - it is a Google IP address. Seems like a terrible waste of their bandwidth. --Jeff From jeffrey at cunningham.net Fri Jul 4 15:22:30 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Fri, 04 Jul 2008 08:22:30 -0700 Subject: [hunchentoot-devel] googlebot revisitation rate excessive? In-Reply-To: <48681B63.40407@cunningham.net> References: <48681B63.40407@cunningham.net> Message-ID: <486E4036.8050800@cunningham.net> I've cleaned up a couple small problems using page validators but the net result has been that the Googlebot has gone from visiting my site every minute or so to every second or so. No kidding. Before I block them altogether, there is one thing I don't understand that I'm hoping someone can explain to me. What does it mean exactly when I get a "No session for session identifier" INFO message in my error_log? There is one of these for each of the Googlebot hits. --Jeff Here is a snippet of the access_log (followed by the corresponding error_log snippet): 127.0.0.1 (66.249.66.195) - [2008-07-04 07:39:32] "GET /zippy.html?hunchentoot-session=482%3A1424DD49911CD85 E35CE168E602686DC HTTP/1.1" 200 4284 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot .html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:39:32] "GET /robogames-2008.html?hunchentoot-session=483%3AFBDE26 FEB3370A5DC63A565E2611DD5A HTTP/1.1" 200 12724 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.goog le.com/bot.html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:39:33] "GET /robogames-2008.html?hunchentoot-session=482%3A1424DD 49911CD85E35CE168E602686DC HTTP/1.1" 200 12724 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.goog le.com/bot.html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:39:34] "GET /zippy.html?hunchentoot-session=485%3A97280661B72EBFC 07C48B8F100FCB60C HTTP/1.1" 200 4284 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot .html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:39:34] "GET /robogames-2008.html?hunchentoot-session=456%3A211AA2 04AD4D3A3703E0FA80DF3D0D51 HTTP/1.1" 200 12724 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.goog le.com/bot.html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:39:35] "GET /zippy.html?hunchentoot-session=289%3A8676A2453C327D6 10DDB4F79A48A61F6 HTTP/1.1" 200 4284 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot .html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:39:36] "GET /zippy.html?hunchentoot-session=177%3A6EF66F58D2E0A59 19AACB700DDB5D435 HTTP/1.1" 200 4284 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot .html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:39:37] "GET /robogames-2008.html?hunchentoot-session=464%3AC5740E 8F90480BCF319EFCD9C7A8EE88 HTTP/1.1" 200 12724 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.goog le.com/bot.html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:42:39] "GET /zippy.html?hunchentoot-session=483%3AFBDE26FEB3370A5 DC63A565E2611DD5A HTTP/1.1" 200 4284 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot .html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:46:28] "GET /zippy.html?hunchentoot-session=478%3AB00C2E319A15E56 58D72E232C36F30DD HTTP/1.1" 200 4284 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot .html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:50:18] "GET /zippy.html?hunchentoot-session=230%3A85588DC64DDDBF9 219B71F4DFA746B50 HTTP/1.1" 200 4284 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot .html)" 127.0.0.1 (66.249.66.195) - [2008-07-04 07:54:08] "GET /zippy.html?hunchentoot-session=145%3A4C7B146A126FC14 ACFC7BFA8100C07D8 HTTP/1.1" 200 4284 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot .html)" HERE'S THE CORRESPONDING ERROR LOG ENTRIES: [2008-07-04 07:39:32 [INFO]] No session for session identifier '483:FBDE26FEB3370A5DC63A565E2611DD5A' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:39:33 [INFO]] No session for session identifier '482:1424DD49911CD85E35CE168E602686DC' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:39:34 [INFO]] No session for session identifier '485:97280661B72EBFC07C48B8F100FCB60C' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:39:34 [INFO]] No session for session identifier '456:211AA204AD4D3A3703E0FA80DF3D0D51' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:39:35 [INFO]] No session for session identifier '289:8676A2453C327D610DDB4F79A48A61F6' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:39:36 [INFO]] No session for session identifier '177:6EF66F58D2E0A5919AACB700DDB5D435' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:39:37 [INFO]] No session for session identifier '464:C5740E8F90480BCF319EFCD9C7A8EE88' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:39:57 [ERROR]] Error while processing connection: I/O timeout reading #. [2008-07-04 07:42:38 [INFO]] No session for session identifier '483:FBDE26FEB3370A5DC63A565E2611DD5A' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:42:59 [ERROR]] Error while processing connection: I/O timeout reading #. [2008-07-04 07:46:28 [INFO]] No session for session identifier '478:B00C2E319A15E5658D72E232C36F30DD' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:46:48 [ERROR]] Error while processing connection: I/O timeout reading #. [2008-07-04 07:50:18 [INFO]] No session for session identifier '230:85588DC64DDDBF9219B71F4DFA746B50' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:50:38 [ERROR]] Error while processing connection: I/O timeout reading #. [2008-07-04 07:54:08 [INFO]] No session for session identifier '145:4C7B146A126FC14ACFC7BFA8100C07D8' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:54:28 [ERROR]] Error while processing connection: I/O timeout reading #. [2008-07-04 07:57:59 [INFO]] No session for session identifier '478:B00C2E319A15E5658D72E232C36F30DD' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 07:58:19 [ERROR]] Error while processing connection: I/O timeout reading #. [2008-07-04 08:01:49 [INFO]] No session for session identifier '493:640F2D5F184258D62527F8BD4AA0B91B' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 08:02:09 [ERROR]] Error while processing connection: I/O timeout reading #. [2008-07-04 08:05:40 [INFO]] No session for session identifier '308:FA7CD1A4C4592F69DA33BE6826383D46' (User- Agent: 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', IP: '127.0.0.1') [2008-07-04 08:06:00 [ERROR]] Error while processing connection: I/O timeout reading #. From hans at huebner.org Fri Jul 4 15:40:51 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 4 Jul 2008 17:40:51 +0200 Subject: [hunchentoot-devel] googlebot revisitation rate excessive? In-Reply-To: <486E4036.8050800@cunningham.net> References: <48681B63.40407@cunningham.net> <486E4036.8050800@cunningham.net> Message-ID: On 7/4/08, Jeff Cunningham wrote: > Before I block them altogether, there is one thing I don't understand that > I'm hoping someone can explain to me. What does it mean exactly when I get a > "No session for session identifier" INFO message in my error_log? There is > one of these for each of the Googlebot hits. It means that googlebot presented a session identifier string as a hunchentoot-session parameter that is not valid. You are propably using sessions very frequently and the Google crawler managed to hit one of the URLs of your server that starts a session. As the crawler did not accept the Cookie that Hunchentoot sent, Hunchentoot fell back to attaching the session identifier to all URLs in the outgoing HTML as a parameter. The crawler saved the URLs it saw including the session identifier and now tries to crawl using these identifiers, which are propably old and no longer valid. First off, I would recommend that you switch of URL-REWRITE (http://weitz.de/hunchentoot/#*rewrite-for-session-urls*). I am not using it myself precisely because it confuses simple crawlers. If a user does not accept the cookies my site sends, they will not be able to use it with sessions. For me, this has never been a problem. This will propably not help you with your current problem, but it will make things easier in the future. In general, crawlers do not support cookies or session ids in GET parameters. Thus, if you want to support crawlers, you need to make them work without sessions. Note that if you just do nothing except switching off URL-REWRITE; every request from a crawler will create a new session. This may or may not be a problem. I guess that Google now has a lot of your URLs it wants to crawl because the different session identifiers made it think that all of them are pointing to different resource. I am kind of wondering whether that is standard googlebot behaviour. Lastly, I would vote for switching off URL-REWRITE by default. -Hans From jeffrey at cunningham.net Fri Jul 4 21:50:39 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Fri, 04 Jul 2008 14:50:39 -0700 Subject: [hunchentoot-devel] googlebot revisitation rate excessive? In-Reply-To: References: <48681B63.40407@cunningham.net> <486E4036.8050800@cunningham.net> Message-ID: <486E9B2F.3080607@cunningham.net> Hans H?bner wrote: > It means that googlebot presented a session identifier string as a > hunchentoot-session parameter that is not valid. You are propably > using sessions very frequently and the Google crawler managed to hit > one of the URLs of your server that starts a session. As the crawler > did not accept the Cookie that Hunchentoot sent, Hunchentoot fell back > to attaching the session identifier to all URLs in the outgoing HTML > as a parameter. The crawler saved the URLs it saw including the > session identifier and now tries to crawl using these identifiers, > which are propably old and no longer valid. > > First off, I would recommend that you switch of URL-REWRITE > (http://weitz.de/hunchentoot/#*rewrite-for-session-urls*). I am not > using it myself precisely because it confuses simple crawlers. If a > user does not accept the cookies my site sends, they will not be able > to use it with sessions. For me, this has never been a problem. This > will propably not help you with your current problem, but it will make > things easier in the future. > > In general, crawlers do not support cookies or session ids in GET > parameters. Thus, if you want to support crawlers, you need to make > them work without sessions. Note that if you just do nothing except > switching off URL-REWRITE; every request from a crawler will create a > new session. This may or may not be a problem. > > I guess that Google now has a lot of your URLs it wants to crawl > because the different session identifiers made it think that all of > them are pointing to different resource. I am kind of wondering > whether that is standard googlebot behaviour. > > Lastly, I would vote for switching off URL-REWRITE by default. > Thanks for the excellent explanation. It fits all the available facts. I've turned off *REWRITE-FOR-SESSION-URLS* so presumably, google should eventually out that the URL's it has are bad and drop them in favor of the sessionless ones (I hope). I switched to a non-googlebotted site to experiment with and for some reason even when I'm not using sessions, I see a message about "No session for session identifier..." when I browse a page myself. I cleared my cache, here's an example: [2008-07-04 14:46:34 [WARNING]] Fake session identifier '1:D5C66E2968BE2162C3164 B39B9029F13' (User-Agent: 'Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14 ) Gecko/20080404 Iceweasel/2.0.0.14 (Debian-2.0.0.14-2)', IP: '127.0.0.1') That error message corresponds to this access log entry and this header output: 127.0.0.1 (192.168.1.1) - [2008-07-04 14:46:34] "GET / HTTP/1.1" 200 9195 "-" "M ozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080404 Iceweasel/2 .0.0.14 (Debian-2.0.0.14-2)" GET / HTTP/1.1 Host: 127.0.0.1:4242 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080404 Iceweasel/2.0.0.14\ (Debian-2.0.0.14-2) 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 Cookie: hunchentoot-session=1%3AD5C66E2968BE2162C3164B39B9029F13 Max-Forwards: 10 X-Forwarded-For: 192.168.1.1 X-Forwarded-Host: cunningham.homeip.net X-Forwarded-Server: test.com Connection: Keep-Alive HTTP/1.1 200 OK Content-Length: 9195^M Date: Fri, 04 Jul 2008 21:46:34 GMT^M Server: Hunchentoot 1.0.0^M Keep-Alive: timeout=20^M Connection: Keep-Alive^M Content-Type: text/html; charset=iso-8859-1^M --Jeff From jeffrey at cunningham.net Sat Jul 5 01:36:29 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Fri, 04 Jul 2008 18:36:29 -0700 Subject: [hunchentoot-devel] googlebot revisitation rate excessive? In-Reply-To: <486E9B2F.3080607@cunningham.net> References: <48681B63.40407@cunningham.net> <486E4036.8050800@cunningham.net> <486E9B2F.3080607@cunningham.net> Message-ID: <486ED01D.40607@cunningham.net> Never mind on the last question, I still had a cookie set in the browser which it was sending back to the server. I thought I'd cleared it. Sorry about the noise. --Jeff From jeffrey at cunningham.net Sat Jul 5 15:02:06 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Sat, 05 Jul 2008 08:02:06 -0700 Subject: [hunchentoot-devel] socket timeout errors Message-ID: <486F8CEE.80702@cunningham.net> Now that I've cleaned the Google forest out of my logs I can see something else that must be wrong. 20 seconds after *every* new set of page GETs in the access_log there is a socket timeout in the error_log: 127.0.0.1 (76.64.38.115) - [2008-07-05 05:54:09] "GET /ts7200.html HTTP/1.1" 200 20220 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0" 127.0.0.1 (76.64.38.115) - [2008-07-05 05:54:09] "GET /images/jandm.ico HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0" [2008-07-05 05:54:29 [ERROR]] Error while processing connection: I/O timeout reading #. I believe this is new behavior since I upgraded hunchentoot and switched from mod_lisp to mod_proxy (with which I am unfamiliar), in case that might have anything to do with it. I don't have any idea what might be going on here. The pages are complete and don't appear to be timing out. Thanks. --Jeff From hans at huebner.org Sun Jul 6 18:48:29 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 6 Jul 2008 20:48:29 +0200 Subject: [hunchentoot-devel] socket timeout errors In-Reply-To: <486F8CEE.80702@cunningham.net> References: <486F8CEE.80702@cunningham.net> Message-ID: On 5. Juli 2008 17:02, Jeff Cunningham wrote: > > Now that I've cleaned the Google forest out of my logs I can see something > else that must be wrong. 20 seconds after *every* new set of page GETs in > the access_log there is a socket timeout in the error_log: > > 127.0.0.1 (76.64.38.115) - [2008-07-05 05:54:09] "GET /ts7200.html HTTP/1.1" > 200 20220 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) > Gecko/2008052906 Firefox/3.0" > 127.0.0.1 (76.64.38.115) - [2008-07-05 05:54:09] "GET /images/jandm.ico > HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) > Gecko/2008052906 Firefox/3.0" > > [2008-07-05 05:54:29 [ERROR]] Error while processing connection: I/O timeout > reading #. > > > I believe this is new behavior since I upgraded hunchentoot and switched > from mod_lisp to mod_proxy (with which I am unfamiliar), in case that might > have anything to do with it. > > I don't have any idea what might be going on here. The pages are complete > and don't appear to be timing out. It is the connections that time out, which is "normal". The error messages are annoying and need to be taken care of, but they are note indicative of a problem. Are you using the release version of Hunchentoot or the Subversion one? -Hans From jeffrey at cunningham.net Sun Jul 6 20:50:07 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Sun, 06 Jul 2008 13:50:07 -0700 Subject: [hunchentoot-devel] socket timeout errors In-Reply-To: References: <486F8CEE.80702@cunningham.net> Message-ID: <48712FFF.1090707@cunningham.net> Hans H?bner wrote: > On 5. Juli 2008 17:02, Jeff Cunningham wrote: > >> Now that I've cleaned the Google forest out of my logs I can see something >> else that must be wrong. 20 seconds after *every* new set of page GETs in >> the access_log there is a socket timeout in the error_log: >> >> 127.0.0.1 (76.64.38.115) - [2008-07-05 05:54:09] "GET /ts7200.html HTTP/1.1" >> 200 20220 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) >> Gecko/2008052906 Firefox/3.0" >> 127.0.0.1 (76.64.38.115) - [2008-07-05 05:54:09] "GET /images/jandm.ico >> HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) >> Gecko/2008052906 Firefox/3.0" >> >> [2008-07-05 05:54:29 [ERROR]] Error while processing connection: I/O timeout >> reading #. >> >> >> I believe this is new behavior since I upgraded hunchentoot and switched >> from mod_lisp to mod_proxy (with which I am unfamiliar), in case that might >> have anything to do with it. >> >> I don't have any idea what might be going on here. The pages are complete >> and don't appear to be timing out. >> > > It is the connections that time out, which is "normal". The error > messages are annoying and need to be taken care of, but they are note > indicative of a problem. Are you using the release version of > Hunchentoot or the Subversion one? > The subversion one. I didn't know about a release one along this development channel. --Jeff > -Hans > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From rlpowell at digitalkingdom.org Mon Jul 7 08:45:18 2008 From: rlpowell at digitalkingdom.org (Robin Lee Powell) Date: Mon, 7 Jul 2008 01:45:18 -0700 Subject: [hunchentoot-devel] Test for running? Message-ID: <20080707084518.GD3190@digitalkingdom.org> So I'm writing code that'll be largely "setup dispatch table, run hunchentoot". I don't really want to do anything after hunchentoot is launched other than, well, hunchentoot, but it seems to thread itself off (fine) and then the REPL terminates (not so fine). I'd like to loop around "Is Hunchentoot still alive?", but I don't know how to test for whether that thread is still running, or if that's even the right kind of test. This is SBCL on Linux, in case it matters. Thanks. -Robin -- Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo Proud Supporter of the Singularity Institute - http://singinst.org/ http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ From avodonosov at yandex.ru Mon Jul 7 20:19:11 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Mon, 7 Jul 2008 23:19:11 +0300 Subject: [hunchentoot-devel] Test for running? In-Reply-To: <20080707084518.GD3190@digitalkingdom.org> References: <20080707084518.GD3190@digitalkingdom.org> Message-ID: <771485665.20080707231911@yandex.ru> Maybe you are using single threaded SBCL? Check the *features* special variable, if the :sb-thread symbol is present - your SBCL is multithreaded, otherwise it is single threaded. In case of single threaded, your single thread is busy by running hunchentoot and REPL is blocked. - Anton on Monday, July 7, 2008, 11:45:18 AM Robin wrote: > So I'm writing code that'll be largely "setup dispatch table, run > hunchentoot". I don't really want to do anything after hunchentoot > is launched other than, well, hunchentoot, but it seems to thread > itself off (fine) and then the REPL terminates (not so fine). > I'd like to loop around "Is Hunchentoot still alive?", but I don't > know how to test for whether that thread is still running, or if > that's even the right kind of test. > This is SBCL on Linux, in case it matters. > Thanks. > -Robin From geocar at gmail.com Mon Jul 7 20:21:39 2008 From: geocar at gmail.com (Geo Carncross) Date: Mon, 7 Jul 2008 16:21:39 -0400 Subject: [hunchentoot-devel] Test for running? In-Reply-To: <20080707084518.GD3190@digitalkingdom.org> References: <20080707084518.GD3190@digitalkingdom.org> Message-ID: <527511140807071321n375c940m53d2c8db09fb5cab@mail.gmail.com> On Mon, Jul 7, 2008 at 4:45 AM, Robin Lee Powell wrote: > > So I'm writing code that'll be largely "setup dispatch table, run > hunchentoot". I don't really want to do anything after hunchentoot > is launched other than, well, hunchentoot, but it seems to thread > itself off (fine) and then the REPL terminates (not so fine). > > I'd like to loop around "Is Hunchentoot still alive?", but I don't > know how to test for whether that thread is still running, or if > that's even the right kind of test. > > This is SBCL on Linux, in case it matters. There are lots of ways to do this; on our systems we run lisp on a separate tty (using /etc/inittab) - this has the added benefit of having /sbin/init restarting it if it dies/is killed. You could also run lisp under GNU screen, which would allow you to connect to it and see the repl if there were any errors. Another option is you could run hunchentoot directly instead of creating a thread for it. If you looked at server.lisp you could figure out how this is done just by looking at start-server. Another option is you could run the sbcl function (sb-ext:process-wait (hunchentoot::server-listener s)) I recommend keeping the repl around; we had a number of problems when we deployed that were fixed "in the field" by connecting to the repl and patching our app while it was running. From andy.arvid at gmail.com Mon Jul 7 22:28:22 2008 From: andy.arvid at gmail.com (Andrew Peterson) Date: Mon, 7 Jul 2008 18:28:22 -0400 Subject: [hunchentoot-devel] Problem with SBCL 1.0.18 Message-ID: <30b9bbc50807071528i59ff555br37699dc205d828b6@mail.gmail.com> Today, I upgraded to SBCL 1.0.18 and Hunchentoot 0.15.7 from SBCL 1.0.12 and Hunchentoot 0.15.2. Unfortunately, when SBCL compiles I got this error: erred while invoking # on # [Condition of type ASDF:COMPILE-FAILED] I also got this error when I returned to Hunchentoot 0.15.2. I returned to SBCL 1.0.12 and Hunchentoot works in both versions (0.15.2 and 0.15.7) andy peterson. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Tue Jul 8 04:54:50 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 8 Jul 2008 06:54:50 +0200 Subject: [hunchentoot-devel] Problem with SBCL 1.0.18 In-Reply-To: <30b9bbc50807071528i59ff555br37699dc205d828b6@mail.gmail.com> References: <30b9bbc50807071528i59ff555br37699dc205d828b6@mail.gmail.com> Message-ID: Andrew, could you check whether you have the same problem when you're using the Hunchentoot development version? It is currently only available through Subversion by checking out http://bknr.net/svn/ediware - If that does not work, too, please send a complete error message of the compilation. Thanks, Hans 2008/7/8 Andrew Peterson : > Today, I upgraded to SBCL 1.0.18 and Hunchentoot 0.15.7 from SBCL 1.0.12 and > Hunchentoot 0.15.2. > > Unfortunately, when SBCL compiles I got this error: > erred while invoking # on > # > [Condition of type ASDF:COMPILE-FAILED] > > I also got this error when I returned to Hunchentoot 0.15.2. > > I returned to SBCL 1.0.12 and Hunchentoot works in both versions (0.15.2 and > 0.15.7) > > andy peterson. > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From andy.arvid at gmail.com Tue Jul 8 14:08:29 2008 From: andy.arvid at gmail.com (Andrew Peterson) Date: Tue, 8 Jul 2008 10:08:29 -0400 Subject: [hunchentoot-devel] Problem with SBCL 1.0.18 In-Reply-To: References: <30b9bbc50807071528i59ff555br37699dc205d828b6@mail.gmail.com> Message-ID: <30b9bbc50807080708g6030bebcya146b3ff14763fe5@mail.gmail.com> Hans, The Hunchentoot development version compiles fine in SBCL 1.0.18 (Linux 64 bits) using all libraries in the ediware tree. SBCL 1.0.18 was compiled from the source using SBCL 1.0.12. I do this by removing all *.fasl in the libraries. then enter (require :hunchentoot) But (defvar *server* (hunchentoot:start-server :port 8080)) does not return. It hangs REPL. But it is running. http://localhost:8080/ returns the default hunchentoot page. The same holds true for SBCL 1.0.17 (binary download). But SBCL 1.0.12 compiles and runs right, start-server does return and my code runs fine. Thanks Andy On Tue, Jul 8, 2008 at 12:54 AM, Hans H?bner wrote: > Andrew, > > could you check whether you have the same problem when you're using > the Hunchentoot development version? It is currently only available > through Subversion by checking out http://bknr.net/svn/ediware - If > that does not work, too, please send a complete error message of the > compilation. > > Thanks, > Hans > > 2008/7/8 Andrew Peterson : > > Today, I upgraded to SBCL 1.0.18 and Hunchentoot 0.15.7 from SBCL 1.0.12 > and > > Hunchentoot 0.15.2. > > > > Unfortunately, when SBCL compiles I got this error: > > erred while invoking # on > > # > > [Condition of type ASDF:COMPILE-FAILED] > > > > I also got this error when I returned to Hunchentoot 0.15.2. > > > > I returned to SBCL 1.0.12 and Hunchentoot works in both versions (0.15.2 > and > > 0.15.7) > > > > andy peterson. > > > > > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- My Exercise Logs: http://andyarvid.infogami.com http://decenturl.com/spreadsheets.google/andys-exercise-log -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Tue Jul 8 14:16:36 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 8 Jul 2008 16:16:36 +0200 Subject: [hunchentoot-devel] Problem with SBCL 1.0.18 In-Reply-To: <30b9bbc50807080708g6030bebcya146b3ff14763fe5@mail.gmail.com> References: <30b9bbc50807071528i59ff555br37699dc205d828b6@mail.gmail.com> <30b9bbc50807080708g6030bebcya146b3ff14763fe5@mail.gmail.com> Message-ID: Andy, did you build SBCL 1.0.18 with threads? From what you write I would guess that you are using a non-threaded Lisp. START-SERVER does not return in this case, as all request processing is done in the foreground. The SBCL 1.0.17 binary that you downloaded should be threaded, though. -Hans 2008/7/8 Andrew Peterson : > Hans, > > The Hunchentoot development version compiles fine in SBCL 1.0.18 (Linux 64 > bits) using all libraries in the ediware tree. > SBCL 1.0.18 was compiled from the source using SBCL 1.0.12. > > I do this by removing all *.fasl in the libraries. then enter > (require :hunchentoot) > But > (defvar *server* (hunchentoot:start-server :port 8080)) > does not return. It hangs REPL. But it is running. > http://localhost:8080/ returns the default hunchentoot page. > > The same holds true for SBCL 1.0.17 (binary download). > > But SBCL 1.0.12 compiles and runs right, start-server does return and my > code runs fine. > > Thanks > > Andy > > On Tue, Jul 8, 2008 at 12:54 AM, Hans H?bner wrote: >> >> Andrew, >> >> could you check whether you have the same problem when you're using >> the Hunchentoot development version? It is currently only available >> through Subversion by checking out http://bknr.net/svn/ediware - If >> that does not work, too, please send a complete error message of the >> compilation. >> >> Thanks, >> Hans >> >> 2008/7/8 Andrew Peterson : >> > Today, I upgraded to SBCL 1.0.18 and Hunchentoot 0.15.7 from SBCL 1.0.12 >> > and >> > Hunchentoot 0.15.2. >> > >> > Unfortunately, when SBCL compiles I got this error: >> > erred while invoking # on >> > # >> > [Condition of type ASDF:COMPILE-FAILED] >> > >> > I also got this error when I returned to Hunchentoot 0.15.2. >> > >> > I returned to SBCL 1.0.12 and Hunchentoot works in both versions (0.15.2 >> > and >> > 0.15.7) >> > >> > andy peterson. >> > >> > >> > >> > _______________________________________________ >> > tbnl-devel site list >> > tbnl-devel at common-lisp.net >> > http://common-lisp.net/mailman/listinfo/tbnl-devel >> > >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > -- > My Exercise Logs: > http://andyarvid.infogami.com > http://decenturl.com/spreadsheets.google/andys-exercise-log > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From andy.arvid at gmail.com Tue Jul 8 15:46:19 2008 From: andy.arvid at gmail.com (Andrew Peterson) Date: Tue, 8 Jul 2008 11:46:19 -0400 Subject: [hunchentoot-devel] Problem with SBCL 1.0.18 In-Reply-To: References: <30b9bbc50807071528i59ff555br37699dc205d828b6@mail.gmail.com> <30b9bbc50807080708g6030bebcya146b3ff14763fe5@mail.gmail.com> Message-ID: <30b9bbc50807080846s43c14d63v5dfb2531119df9ef@mail.gmail.com> Hans, This appears to be the case with SBCL 1.0.18 and SBCL 1.0.17. In both cases :sb-thread is not in *features* and if I (pushnew :sb-thread *features) (defvar *server* (hunchentoot:start-server :port 8080)) now returns the error: Not supported in unithread builds. I built 1.0.18 with the instructions on SBCL site (sh make.sh). So it is built with whatever default configuration is within the make files. I will advise SBCL of the problem and try to figure out how to build with threads. Thanks for being so responsive, andy On Tue, Jul 8, 2008 at 10:16 AM, Hans H?bner wrote: > Andy, > > did you build SBCL 1.0.18 with threads? From what you write I would > guess that you are using a non-threaded Lisp. START-SERVER does not > return in this case, as all request processing is done in the > foreground. The SBCL 1.0.17 binary that you downloaded should be > threaded, though. > > -Hans > > 2008/7/8 Andrew Peterson : > > Hans, > > > > The Hunchentoot development version compiles fine in SBCL 1.0.18 (Linux > 64 > > bits) using all libraries in the ediware tree. > > SBCL 1.0.18 was compiled from the source using SBCL 1.0.12. > > > > I do this by removing all *.fasl in the libraries. then enter > > (require :hunchentoot) > > But > > (defvar *server* (hunchentoot:start-server :port 8080)) > > does not return. It hangs REPL. But it is running. > > http://localhost:8080/ returns the default hunchentoot page. > > > > The same holds true for SBCL 1.0.17 (binary download). > > > > But SBCL 1.0.12 compiles and runs right, start-server does return and my > > code runs fine. > > > > Thanks > > > > Andy > > > > On Tue, Jul 8, 2008 at 12:54 AM, Hans H?bner wrote: > >> > >> Andrew, > >> > >> could you check whether you have the same problem when you're using > >> the Hunchentoot development version? It is currently only available > >> through Subversion by checking out http://bknr.net/svn/ediware - If > >> that does not work, too, please send a complete error message of the > >> compilation. > >> > >> Thanks, > >> Hans > >> > >> 2008/7/8 Andrew Peterson : > >> > Today, I upgraded to SBCL 1.0.18 and Hunchentoot 0.15.7 from SBCL > 1.0.12 > >> > and > >> > Hunchentoot 0.15.2. > >> > > >> > Unfortunately, when SBCL compiles I got this error: > >> > erred while invoking # on > >> > # > >> > [Condition of type ASDF:COMPILE-FAILED] > >> > > >> > I also got this error when I returned to Hunchentoot 0.15.2. > >> > > >> > I returned to SBCL 1.0.12 and Hunchentoot works in both versions > (0.15.2 > >> > and > >> > 0.15.7) > >> > > >> > andy peterson. > >> > > >> > > >> > > >> > _______________________________________________ > >> > tbnl-devel site list > >> > tbnl-devel at common-lisp.net > >> > http://common-lisp.net/mailman/listinfo/tbnl-devel > >> > > >> _______________________________________________ > >> tbnl-devel site list > >> tbnl-devel at common-lisp.net > >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > > > > > -- > > My Exercise Logs: > > http://andyarvid.infogami.com > > http://decenturl.com/spreadsheets.google/andys-exercise-log > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- My Exercise Logs: http://andyarvid.infogami.com http://decenturl.com/spreadsheets.google/andys-exercise-log -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch-tbnl at bobobeach.com Tue Jul 8 16:43:56 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Tue, 8 Jul 2008 09:43:56 -0700 Subject: [hunchentoot-devel] Problem with SBCL 1.0.18 In-Reply-To: <30b9bbc50807080846s43c14d63v5dfb2531119df9ef@mail.gmail.com> References: <30b9bbc50807071528i59ff555br37699dc205d828b6@mail.gmail.com> <30b9bbc50807080708g6030bebcya146b3ff14763fe5@mail.gmail.com> <30b9bbc50807080846s43c14d63v5dfb2531119df9ef@mail.gmail.com> Message-ID: There isn't an SBCL problem, you just need to enable threads when you build SBCL. See Christophe Rhode's recent message to sbcl-devel: > You need to create a file called customize-target-features.lisp in the > sbcl source directory, containing something like > (lambda (list) (list* :sb-thread list)) > (see section 2.2 of the INSTALL file) Cyrus On Jul 8, 2008, at 8:46 AM, Andrew Peterson wrote: > Hans, > > This appears to be the case with SBCL 1.0.18 and SBCL 1.0.17. > In both cases :sb-thread is not in *features* and if I (pushnew :sb- > thread *features) > (defvar *server* (hunchentoot:start-server :port 8080)) > now returns the error: Not supported in unithread builds. > > I built 1.0.18 with the instructions on SBCL site (sh make.sh). > So it is built with whatever default configuration is within the > make files. > > I will advise SBCL of the problem and try to figure out how to build > with threads. > > Thanks for being so responsive, > > andy > > On Tue, Jul 8, 2008 at 10:16 AM, Hans H?bner wrote: > Andy, > > did you build SBCL 1.0.18 with threads? From what you write I would > guess that you are using a non-threaded Lisp. START-SERVER does not > return in this case, as all request processing is done in the > foreground. The SBCL 1.0.17 binary that you downloaded should be > threaded, though. > > -Hans > > 2008/7/8 Andrew Peterson : > > Hans, > > > > The Hunchentoot development version compiles fine in SBCL 1.0.18 > (Linux 64 > > bits) using all libraries in the ediware tree. > > SBCL 1.0.18 was compiled from the source using SBCL 1.0.12. > > > > I do this by removing all *.fasl in the libraries. then enter > > (require :hunchentoot) > > But > > (defvar *server* (hunchentoot:start-server :port 8080)) > > does not return. It hangs REPL. But it is running. > > http://localhost:8080/ returns the default hunchentoot page. > > > > The same holds true for SBCL 1.0.17 (binary download). > > > > But SBCL 1.0.12 compiles and runs right, start-server does return > and my > > code runs fine. > > > > Thanks > > > > Andy > > > > On Tue, Jul 8, 2008 at 12:54 AM, Hans H?bner > wrote: > >> > >> Andrew, > >> > >> could you check whether you have the same problem when you're using > >> the Hunchentoot development version? It is currently only > available > >> through Subversion by checking out http://bknr.net/svn/ediware - If > >> that does not work, too, please send a complete error message of > the > >> compilation. > >> > >> Thanks, > >> Hans > >> > >> 2008/7/8 Andrew Peterson : > >> > Today, I upgraded to SBCL 1.0.18 and Hunchentoot 0.15.7 from > SBCL 1.0.12 > >> > and > >> > Hunchentoot 0.15.2. > >> > > >> > Unfortunately, when SBCL compiles I got this error: > >> > erred while invoking # on > >> > # > >> > [Condition of type ASDF:COMPILE-FAILED] > >> > > >> > I also got this error when I returned to Hunchentoot 0.15.2. > >> > > >> > I returned to SBCL 1.0.12 and Hunchentoot works in both > versions (0.15.2 > >> > and > >> > 0.15.7) > >> > > >> > andy peterson. > >> > > >> > > >> > > >> > _______________________________________________ > >> > tbnl-devel site list > >> > tbnl-devel at common-lisp.net > >> > http://common-lisp.net/mailman/listinfo/tbnl-devel > >> > > >> _______________________________________________ > >> tbnl-devel site list > >> tbnl-devel at common-lisp.net > >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > > > > > -- > > My Exercise Logs: > > http://andyarvid.infogami.com > > http://decenturl.com/spreadsheets.google/andys-exercise-log > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > -- > My Exercise Logs: > http://andyarvid.infogami.com > http://decenturl.com/spreadsheets.google/andys-exercise-log > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.arvid at gmail.com Tue Jul 8 18:22:14 2008 From: andy.arvid at gmail.com (Andrew Peterson) Date: Tue, 8 Jul 2008 14:22:14 -0400 Subject: [hunchentoot-devel] Problem with SBCL 1.0.18 In-Reply-To: References: <30b9bbc50807071528i59ff555br37699dc205d828b6@mail.gmail.com> <30b9bbc50807080708g6030bebcya146b3ff14763fe5@mail.gmail.com> <30b9bbc50807080846s43c14d63v5dfb2531119df9ef@mail.gmail.com> Message-ID: <30b9bbc50807081122s3ddb16adufd62b535dd6a8332@mail.gmail.com> Yes, You need to create customize-target-features.lisp in the source code directory with (lambda (features) (flet ((enable (x) (pushnew x features)) (disable (x) (setf features (remove x features)))) ;; Threading support, available only on x86/x86-64 Linux, x86 Solaris ;; and x86 Mac OS X (experimental). (enable :sb-thread))) I rebuilt SBCL 1.0.18 and hunchentoot svn version and version 0.15.7 work fine. Thanks, andy On Tue, Jul 8, 2008 at 12:43 PM, Cyrus Harmon wrote: > > There isn't an SBCL problem, you just need to enable threads when you build > SBCL. See Christophe Rhode's recent message to sbcl-devel: > > You need to create a file called customize-target-features.lisp in the > sbcl source directory, containing something like > (lambda (list) (list* :sb-thread list)) > (see section 2.2 of the INSTALL file) > > > Cyrus > > On Jul 8, 2008, at 8:46 AM, Andrew Peterson wrote: > > Hans, > > This appears to be the case with SBCL 1.0.18 and SBCL 1.0.17. > In both cases :sb-thread is not in *features* and if I (pushnew :sb-thread > *features) > (defvar *server* (hunchentoot:start-server :port 8080)) > now returns the error: Not supported in unithread builds. > > I built 1.0.18 with the instructions on SBCL site (sh make.sh). > So it is built with whatever default configuration is within the make > files. > > I will advise SBCL of the problem and try to figure out how to build with > threads. > > Thanks for being so responsive, > > andy > > On Tue, Jul 8, 2008 at 10:16 AM, Hans H?bner wrote: > >> Andy, >> >> did you build SBCL 1.0.18 with threads? From what you write I would >> guess that you are using a non-threaded Lisp. START-SERVER does not >> return in this case, as all request processing is done in the >> foreground. The SBCL 1.0.17 binary that you downloaded should be >> threaded, though. >> >> -Hans >> >> 2008/7/8 Andrew Peterson : >> > Hans, >> > >> > The Hunchentoot development version compiles fine in SBCL 1.0.18 (Linux >> 64 >> > bits) using all libraries in the ediware tree. >> > SBCL 1.0.18 was compiled from the source using SBCL 1.0.12. >> > >> > I do this by removing all *.fasl in the libraries. then enter >> > (require :hunchentoot) >> > But >> > (defvar *server* (hunchentoot:start-server :port 8080)) >> > does not return. It hangs REPL. But it is running. >> > http://localhost:8080/ returns the default hunchentoot page. >> > >> > The same holds true for SBCL 1.0.17 (binary download). >> > >> > But SBCL 1.0.12 compiles and runs right, start-server does return and my >> > code runs fine. >> > >> > Thanks >> > >> > Andy >> > >> > On Tue, Jul 8, 2008 at 12:54 AM, Hans H?bner wrote: >> >> >> >> Andrew, >> >> >> >> could you check whether you have the same problem when you're using >> >> the Hunchentoot development version? It is currently only available >> >> through Subversion by checking out http://bknr.net/svn/ediware - If >> >> that does not work, too, please send a complete error message of the >> >> compilation. >> >> >> >> Thanks, >> >> Hans >> >> >> >> 2008/7/8 Andrew Peterson : >> >> > Today, I upgraded to SBCL 1.0.18 and Hunchentoot 0.15.7 from SBCL >> 1.0.12 >> >> > and >> >> > Hunchentoot 0.15.2. >> >> > >> >> > Unfortunately, when SBCL compiles I got this error: >> >> > erred while invoking # on >> >> > # >> >> > [Condition of type ASDF:COMPILE-FAILED] >> >> > >> >> > I also got this error when I returned to Hunchentoot 0.15.2. >> >> > >> >> > I returned to SBCL 1.0.12 and Hunchentoot works in both versions >> (0.15.2 >> >> > and >> >> > 0.15.7) >> >> > >> >> > andy peterson. >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > tbnl-devel site list >> >> > tbnl-devel at common-lisp.net >> >> > http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> > >> >> _______________________________________________ >> >> tbnl-devel site list >> >> tbnl-devel at common-lisp.net >> >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > >> > >> > >> > -- >> > My Exercise Logs: >> > http://andyarvid.infogami.com >> > http://decenturl.com/spreadsheets.google/andys-exercise-log >> > _______________________________________________ >> > tbnl-devel site list >> > tbnl-devel at common-lisp.net >> > http://common-lisp.net/mailman/listinfo/tbnl-devel >> > >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > > > -- > My Exercise Logs: > http://andyarvid.infogami.com > http://decenturl.com/spreadsheets.google/andys-exercise-log_______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch-tbnl at bobobeach.com Tue Jul 8 23:59:14 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Tue, 8 Jul 2008 16:59:14 -0700 Subject: [hunchentoot-devel] feature request Message-ID: Currently, if a file is setup for logging and some other program modifies the file, subsequent log messages fail with a message like this: [2008-07-08 16:56:00 [ERROR]] Error while processing connection: I/O timeout reading #. It would be nice if we trapped this error and reopened the file for appending at this point instead of just timing out. Not sure how involved this is though. Figured I'd record the intention here for posterity's sake in case I never get around to trying to do this. thanks, Cyrus From hans at huebner.org Wed Jul 9 04:18:11 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 9 Jul 2008 06:18:11 +0200 Subject: [hunchentoot-devel] feature request In-Reply-To: References: Message-ID: 2008/7/9 Cyrus Harmon : > > Currently, if a file is setup for logging and some other program modifies > the file, subsequent log messages fail with a message like this: > > [2008-07-08 16:56:00 [ERROR]] Error while processing connection: I/O timeout > reading #. I don't think that the I/O timeout message is related to reopening the log file - As you can see in the error message, there was an operation on a socket stream, not a file, and as I explained in a previous mail, these timeout messages will be trapped in the future, as they are not indicative of an error. > It would be nice if we trapped this error and reopened the file for > appending at this point instead of just timing out. Not sure how involved > this is though. Figured I'd record the intention here for posterity's sake > in case I never get around to trying to do this. You need to use the (setf *log-pathname*) and (setf *access-log-pathname*) accessors to force Hunchentoot to reopen the log files. I think there is no portable way to determine if a file has been changed by some other program or to force appending like in Unix' O_APPEND, but I could be wrong. We don't really want to introduce a platform dependency for this, or do we? -Hans From hans at huebner.org Wed Jul 9 05:53:57 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 9 Jul 2008 07:53:57 +0200 Subject: [hunchentoot-devel] feature request In-Reply-To: References: Message-ID: 2008/7/9 Hans H?bner : > 2008/7/9 Cyrus Harmon : >> >> Currently, if a file is setup for logging and some other program modifies >> the file, subsequent log messages fail with a message like this: >> >> [2008-07-08 16:56:00 [ERROR]] Error while processing connection: I/O timeout >> reading #. I tried reproducing this: With SBCL-1.0.18.16, I see no timeout messages in my error log. With CCL, I saw them but I fixed and committed that problem. Note that you need the usocket version from our Subversion. The release version does not convert conditions properly. -Hans From mathias.dahl at gmail.com Thu Jul 10 15:13:47 2008 From: mathias.dahl at gmail.com (Mathias Dahl) Date: Thu, 10 Jul 2008 17:13:47 +0200 Subject: [hunchentoot-devel] SLIME + SBCL + Hunchentoot on Windows XP - how do I stop the server Message-ID: <7dbe73ed0807100813p32137f89qa7adc96205d93071@mail.gmail.com> Hi! I have got SLIME + SBCL + Hunchentoot working on Windows XP, serving a small web app. I also access a small SQLITE database via CLSQL, which works too. All is well but the fact that once I started Hunchentoot from within SLIME, it locks up SLIME. I assume this is because there is no thread support in SBCL under Windows. However, I can live with this if only I knew a way to stop Hunchentoot. Then I could evaluate whatever new or changed stuff on the REPL and then start the server again. I tried C-c C-c (Interrupt Command) but that killed SLIME and SBCL). Any hints? /Mathias From avodonosov at yandex.ru Thu Jul 10 19:03:55 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Thu, 10 Jul 2008 22:03:55 +0300 Subject: [hunchentoot-devel] SLIME + SBCL + Hunchentoot on Windows XP - how do I stop the server In-Reply-To: <7dbe73ed0807100813p32137f89qa7adc96205d93071@mail.gmail.com> References: <7dbe73ed0807100813p32137f89qa7adc96205d93071@mail.gmail.com> Message-ID: <1015093398.20080710220355@yandex.ru> Hello. There is a very interesting article about how to use Hunchentoot + Slime in single threaded lisp here: http://avodonosov.blogspot.com/2008/01/it-is-problematic-at-first-sight-to-use.html Although it works better with Clisp on Windows because SBCL doesn't close sockets. Best regards, -Anton on Thursday, July 10, 2008, 6:13:47 PM Mathias wrote: > Hi! > I have got SLIME + SBCL + Hunchentoot working on Windows XP, serving a > small web app. I also access a small SQLITE database via CLSQL, which > works too. All is well but the fact that once I started Hunchentoot > from within SLIME, it locks up SLIME. I assume this is because there > is no thread support in SBCL under Windows. However, I can live with > this if only I knew a way to stop Hunchentoot. Then I could evaluate > whatever new or changed stuff on the REPL and then start the server > again. I tried C-c C-c (Interrupt Command) but that killed SLIME and > SBCL). > Any hints? > /Mathias > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From ch-tbnl at bobobeach.com Fri Jul 11 07:20:41 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Fri, 11 Jul 2008 00:20:41 -0700 Subject: [hunchentoot-devel] hunchentoot-cgi and the new hunchentoot regime Message-ID: <487709C9.70708@bobobeach.com> So... I'm trying to convert my hunchentoot-cgi over to the new hunchentoot and running into some problems. My old approach was to do: (progn (let* ((return-code (tbnl::return-code)) (reason-phrase (reason-phrase return-code)) (first-line (format nil "HTTP/1.1 ~D ~A" return-code reason-phrase))) (write-sequence (map 'list #'char-code first-line) out) (write-sequence tbnl::+crlf+ out) (tbnl::maybe-write-to-header-stream first-line)) (setf tbnl::*headers-sent* t) (setf (tbnl::content-type) nil) (sb-ext::run-program path nil :output out :environment env) nil) but this doesn't seem to work anymore. My new approach is to try to use send-headers, but with some hackery to make it optionally more cgi-friendly: Index: headers.lisp =================================================================== --- headers.lisp (revision 3423) +++ headers.lisp (working copy) @@ -70,6 +70,8 @@ (:method (key value) (write-header-line key (princ-to-string value)))) +(defparameter *cgi-hack* nil) + (defun start-output (&key (content nil content-provided-p) (request *request*)) "Sends all headers and maybe the content body to @@ -84,7 +86,8 @@ ;; Read post data to clear stream - Force binary mode to avoid OCTETS-TO-STRING overhead. (raw-post-data :force-binary t) (let* ((return-code (return-code)) - (chunkedp (and (server-output-chunking-p *server*) + (chunkedp (and (not *cgi-hack*) + (server-output-chunking-p *server*) (eq (server-protocol request) :http/1.1) ;; only turn chunking on if the content ;; length is unknown at this point... @@ -196,12 +199,14 @@ ;; write all headers from the REPLY object (loop for (key . value) in (headers-out) when value - do (write-header-line (as-capitalized-string key) value)) + do (unless (and *cgi-hack* (equal key :content-type)) + (write-header-line (as-capitalized-string key) value))) ;; now the cookies (loop for (nil . cookie) in (cookies-out) do (write-header-line "Set-Cookie" (stringify-cookie cookie))) ;; all headers sent - (write-sequence +crlf+ *hunchentoot-stream*) + (unless *cgi-hack* + (write-sequence +crlf+ *hunchentoot-stream*)) (maybe-write-to-header-stream "") ;; access log message (when-let (access-logger (server-access-logger *server*)) The motivation for this hack being that the CGI script wants to send the content-type header, so we can't finish the headers here when running a CGI script. Then I can do: (let* ((tbnl::*cgi-hack* t) (stream (flexi-streams:make-flexi-stream (tbnl:send-headers) :external-format tbnl::+latin-1+))) (sb-ext::run-program path nil :output stream :environment env)) and this sort of works, but, 1) it's kind of a hack and 2) it either exacerbates the timeout situation or there's some other problem where the first request is handled promptly, but subsequent requests to 10 seconds or so while something times out. Not sure why this would be. any thoughts on a good way to handle this? thanks, Cyrus From mathias.dahl at gmail.com Fri Jul 11 23:39:43 2008 From: mathias.dahl at gmail.com (Mathias Dahl) Date: Sat, 12 Jul 2008 01:39:43 +0200 Subject: [hunchentoot-devel] SLIME + SBCL + Hunchentoot on Windows XP - how do I stop the server In-Reply-To: <1015093398.20080710220355@yandex.ru> References: <7dbe73ed0807100813p32137f89qa7adc96205d93071@mail.gmail.com> <1015093398.20080710220355@yandex.ru> Message-ID: <7dbe73ed0807111639j4fe432d3r544b1ca9d5f4c861@mail.gmail.com> Cool! I might even try that out :) Still I would like to know if there is any way to stop the Hunchentoot server. That would be enough for most purposes although not as convenient as under SBCL on GNU/Linux. Anyway, thanks for the link, I will look into it. /Mathias On Thu, Jul 10, 2008 at 9:03 PM, Anton Vodonosov wrote: > Hello. > > There is a very interesting article about how to use > Hunchentoot + Slime in single threaded lisp here: > http://avodonosov.blogspot.com/2008/01/it-is-problematic-at-first-sight-to-use.html > > Although it works better with Clisp on Windows because > SBCL doesn't close sockets. > > Best regards, > -Anton > > on Thursday, July 10, 2008, 6:13:47 PM Mathias wrote: > >> Hi! > >> I have got SLIME + SBCL + Hunchentoot working on Windows XP, serving a >> small web app. I also access a small SQLITE database via CLSQL, which >> works too. All is well but the fact that once I started Hunchentoot >> from within SLIME, it locks up SLIME. I assume this is because there >> is no thread support in SBCL under Windows. However, I can live with >> this if only I knew a way to stop Hunchentoot. Then I could evaluate >> whatever new or changed stuff on the REPL and then start the server >> again. I tried C-c C-c (Interrupt Command) but that killed SLIME and >> SBCL). > >> Any hints? > >> /Mathias >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > From avodonosov at yandex.ru Sat Jul 12 09:56:45 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Sat, 12 Jul 2008 12:56:45 +0300 Subject: [hunchentoot-devel] SLIME + SBCL + Hunchentoot on Windows XP - how do I stop the server In-Reply-To: <7dbe73ed0807111639j4fe432d3r544b1ca9d5f4c861@mail.gmail.com> References: <7dbe73ed0807100813p32137f89qa7adc96205d93071@mail.gmail.com> <1015093398.20080710220355@yandex.ru> <7dbe73ed0807111639j4fe432d3r544b1ca9d5f4c861@mail.gmail.com> Message-ID: <7910595461.20080712125645@yandex.ru> Hm.. My example is ready to use, just download the code. Stopping the server is also included... on Saturday, July 12, 2008, 2:39:43 AM Mathias wrote: > Cool! I might even try that out :) Still I would like to know if there > is any way to stop the Hunchentoot server. That would be enough for > most purposes although not as convenient as under SBCL on GNU/Linux. > Anyway, thanks for the link, I will look into it. > /Mathias > On Thu, Jul 10, 2008 at 9:03 PM, Anton Vodonosov wrote: >> Hello. >> >> There is a very interesting article about how to use >> Hunchentoot + Slime in single threaded lisp here: >> http://avodonosov.blogspot.com/2008/01/it-is-problematic-at-first-sight-to-use.html >> >> Although it works better with Clisp on Windows because >> SBCL doesn't close sockets. >> >> Best regards, >> -Anton >> >> on Thursday, July 10, 2008, 6:13:47 PM Mathias wrote: >> >>> Hi! >> >>> I have got SLIME + SBCL + Hunchentoot working on Windows XP, serving a >>> small web app. I also access a small SQLITE database via CLSQL, which >>> works too. All is well but the fact that once I started Hunchentoot >>> from within SLIME, it locks up SLIME. I assume this is because there >>> is no thread support in SBCL under Windows. However, I can live with >>> this if only I knew a way to stop Hunchentoot. Then I could evaluate >>> whatever new or changed stuff on the REPL and then start the server >>> again. I tried C-c C-c (Interrupt Command) but that killed SLIME and >>> SBCL). >> >>> Any hints? >> >>> /Mathias >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> >> From mathias.dahl at gmail.com Sat Jul 12 10:51:30 2008 From: mathias.dahl at gmail.com (Mathias Dahl) Date: Sat, 12 Jul 2008 12:51:30 +0200 Subject: [hunchentoot-devel] Re: SLIME + SBCL + Hunchentoot on Windows XP - how do I stop the server In-Reply-To: <7910595461.20080712125645@yandex.ru> References: <7dbe73ed0807100813p32137f89qa7adc96205d93071@mail.gmail.com> <1015093398.20080710220355@yandex.ru> <7dbe73ed0807111639j4fe432d3r544b1ca9d5f4c861@mail.gmail.com> <7910595461.20080712125645@yandex.ru> Message-ID: <7dbe73ed0807120351w567685f9y7e0bec4f6a628531@mail.gmail.com> Sorry, I did not mean to say that your hack would not solve my problem. It's just that I wanted a really simple way to stop the server, that's it. What I tried myself was to create a handler for a stop-server, but that did not work because the variable where I stored the server object seemed to be empty. Maybe that is because the server never returns on a single thread SBCL? 2008/7/12, Anton Vodonosov : > Hm.. My example is ready to use, just download the > code. Stopping the server is also included... > > on Saturday, July 12, 2008, 2:39:43 AM Mathias wrote: > >> Cool! I might even try that out :) Still I would like to know if there >> is any way to stop the Hunchentoot server. That would be enough for >> most purposes although not as convenient as under SBCL on GNU/Linux. > >> Anyway, thanks for the link, I will look into it. > >> /Mathias > >> On Thu, Jul 10, 2008 at 9:03 PM, Anton Vodonosov >> wrote: >>> Hello. >>> >>> There is a very interesting article about how to use >>> Hunchentoot + Slime in single threaded lisp here: >>> http://avodonosov.blogspot.com/2008/01/it-is-problematic-at-first-sight-to-use.html >>> >>> Although it works better with Clisp on Windows because >>> SBCL doesn't close sockets. >>> >>> Best regards, >>> -Anton >>> >>> on Thursday, July 10, 2008, 6:13:47 PM Mathias wrote: >>> >>>> Hi! >>> >>>> I have got SLIME + SBCL + Hunchentoot working on Windows XP, serving a >>>> small web app. I also access a small SQLITE database via CLSQL, which >>>> works too. All is well but the fact that once I started Hunchentoot >>>> from within SLIME, it locks up SLIME. I assume this is because there >>>> is no thread support in SBCL under Windows. However, I can live with >>>> this if only I knew a way to stop Hunchentoot. Then I could evaluate >>>> whatever new or changed stuff on the REPL and then start the server >>>> again. I tried C-c C-c (Interrupt Command) but that killed SLIME and >>>> SBCL). >>> >>>> Any hints? >>> >>>> /Mathias >>>> _______________________________________________ >>>> tbnl-devel site list >>>> tbnl-devel at common-lisp.net >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>> >>> >>> > > > From avodonosov at yandex.ru Sat Jul 12 11:48:59 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Sat, 12 Jul 2008 15:48:59 +0400 Subject: [hunchentoot-devel] Re: SLIME + SBCL + Hunchentoot on Windows XP - how do I stop the server In-Reply-To: <7dbe73ed0807120351w567685f9y7e0bec4f6a628531@mail.gmail.com> References: <7dbe73ed0807100813p32137f89qa7adc96205d93071@mail.gmail.com> <1015093398.20080710220355@yandex.ru> <7dbe73ed0807111639j4fe432d3r544b1ca9d5f4c861@mail.gmail.com> <7910595461.20080712125645@yandex.ru> <7dbe73ed0807120351w567685f9y7e0bec4f6a628531@mail.gmail.com> Message-ID: <493171215863339@webmail22.yandex.ru> 12.07.08, 14:51, "Mathias Dahl" mathias.dahl at gmail.com: > Sorry, I did not mean to say that your hack would not solve my > problem. It's just that I wanted a really simple way to stop the > server, that's it. What I tried myself was to create a handler for a > stop-server, but that did not work because the variable where I stored > the server object seemed to be empty. Maybe that is because the server > never returns on a single thread SBCL? Sure. HUNCHENTOOT:START-SEVER is not returned yet and the variable is not assigned. What I do is wrap HUNCHENTOOT:START-SERVER into CATCH and then THROW from the "handler for a stop-server" Best regards, - Anton From mathias.dahl at gmail.com Mon Jul 14 12:03:03 2008 From: mathias.dahl at gmail.com (Mathias Dahl) Date: Mon, 14 Jul 2008 14:03:03 +0200 Subject: [hunchentoot-devel] Re: SLIME + SBCL + Hunchentoot on Windows XP - how do I stop the server In-Reply-To: <493171215863339@webmail22.yandex.ru> References: <7dbe73ed0807100813p32137f89qa7adc96205d93071@mail.gmail.com> <1015093398.20080710220355@yandex.ru> <7dbe73ed0807111639j4fe432d3r544b1ca9d5f4c861@mail.gmail.com> <7910595461.20080712125645@yandex.ru> <7dbe73ed0807120351w567685f9y7e0bec4f6a628531@mail.gmail.com> <493171215863339@webmail22.yandex.ru> Message-ID: <7dbe73ed0807140503l41426a8dy97b82c1edcf254f@mail.gmail.com> > Sure. HUNCHENTOOT:START-SEVER is not returned yet and the variable is not assigned. > What I do is wrap HUNCHENTOOT:START-SERVER into CATCH > and then THROW from the "handler for a stop-server" Aaaah, clever. That did the trick for me, thanks! /Mathias From info at jensteich.de Wed Jul 16 20:17:28 2008 From: info at jensteich.de (Jens Teich) Date: Wed, 16 Jul 2008 22:17:28 +0200 Subject: [hunchentoot-devel] form array Message-ID: <487E5758.1090304@jensteich.de> Maybe this is only a problem of my wrong handling of html forms. I try to set up a group of checkboxes like this:
... I try to get the user input into a Lisp array with an easy-handler but get only an empty array. When clicking the submit button I see an URL like test.html?array%5B%5D=on... where I expect test.html?array[0]=on... If this is already my problem it has nothing to do with huchentoot, but I would appreciate any kind of help ... Thanks Jens From jackalmage at gmail.com Wed Jul 16 20:46:37 2008 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 16 Jul 2008 15:46:37 -0500 Subject: [hunchentoot-devel] form array In-Reply-To: <487E5758.1090304@jensteich.de> References: <487E5758.1090304@jensteich.de> Message-ID: On Wed, Jul 16, 2008 at 3:17 PM, Jens Teich wrote: > Maybe this is only a problem of my wrong handling of html forms. > > I try to set up a group of checkboxes like this: > > > > > > ... > > I try to get the user input into a Lisp array with an easy-handler but get > only an empty array. The name='array[]' syntax is useful in php which actually *uses* that sort of syntax to assign values to an array, but the docs indicate that hunchentoot requires you to actually specify a non-negative integer as the index for the array value. So, you would need to do something like name="array[0]", name="array[1]", etc. When clicking the submit button I see an URL like > > test.html?array%5B%5D=on... > > where I expect > > test.html?array[0]=on... > > If this is already my problem it has nothing to do with huchentoot, but I > would appreciate any kind of help ... There is absolutely nothing wrong with that. The bracket characters aren't allowed in a url, and so are url-encoded automagically by the browser. ~TJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at jensteich.de Wed Jul 16 21:07:05 2008 From: info at jensteich.de (Jens Teich) Date: Wed, 16 Jul 2008 23:07:05 +0200 Subject: [hunchentoot-devel] form array In-Reply-To: References: <487E5758.1090304@jensteich.de> Message-ID: <487E62F9.60805@jensteich.de> Tab Atkins Jr. schrieb: > So, you would need to do something like > name="array[0]", name="array[1]", etc. That works, thanks! Jens From avodonosov at yandex.ru Fri Jul 18 01:00:46 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Fri, 18 Jul 2008 04:00:46 +0300 Subject: [hunchentoot-devel] thread pool benchmark results Message-ID: <801202904.20080718040046@yandex.ru> Hello. I have set up a little benchmark to test ithow thread pool may improve the hunchentoot performance. In two words it looks useful. Details are below. I'm running hunchentoot on a linux VPS with 360 MB of memory, SBCL 1.0.11. It serves little html-template page, the template is filled from an in-memory object. Testing is performed by the AbacheBench tool: ab -c 10 -n 10000 http://localhost:4242/view-order?order-id=1 -n 10000 means total number of requests is 10000 -c 10 means that the requests are issued by 10 concurrent threads Result for the unmodified hunchentoot 0.15.7 was 163 requests per second. For slightly modified version with thread pool it was 1295 request per second. Full AbacheBench reports for the both versions are attached. Patch for port-sbcl.lisp with the simple thread pool implementation is also attached. It is against 0.15.7, sorry it's not for the current development version of hunchentoot, but I created this thead pool code about half a year ago. Best regards, -Anton -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pooled.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: port-sbcl.diff Type: application/octet-stream Size: 5045 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nonpooled.txt URL: From hans at huebner.org Fri Jul 18 04:34:27 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 18 Jul 2008 06:34:27 +0200 Subject: [hunchentoot-devel] thread pool benchmark results In-Reply-To: <801202904.20080718040046@yandex.ru> References: <801202904.20080718040046@yandex.ru> Message-ID: On Fri, Jul 18, 2008 at 03:00, Anton Vodonosov wrote: > I have set up a little benchmark to test ithow > thread pool may improve the hunchentoot performance. > > In two words it looks useful. Details are below. [...] > Patch for port-sbcl.lisp with the simple thread pool > implementation is also attached. It is against 0.15.7, > sorry it's not for the current development version of > hunchentoot, but I created this thead pool code about > half a year ago. I think we would accept performance patches to the development version. The revised connection management should make it easier to integrate thread pooling in a portable fashion. -Hans From avodonosov at yandex.ru Fri Jul 18 04:37:38 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Fri, 18 Jul 2008 07:37:38 +0300 Subject: [hunchentoot-devel] thread pool benchmark results In-Reply-To: References: <801202904.20080718040046@yandex.ru> Message-ID: <984120883.20080718073738@yandex.ru> on Friday, July 18, 2008, 7:34:27 AM Hans wrote: > On Fri, Jul 18, 2008 at 03:00, Anton Vodonosov wrote: >> I have set up a little benchmark to test ithow >> thread pool may improve the hunchentoot performance. >> >> In two words it looks useful. Details are below. > [...] >> Patch for port-sbcl.lisp with the simple thread pool >> implementation is also attached. It is against 0.15.7, >> sorry it's not for the current development version of >> hunchentoot, but I created this thead pool code about >> half a year ago. > I think we would accept performance patches to the development > version. The revised connection management should make it easier to > integrate thread pooling in a portable fashion. > -Hans It was mostly for information. -Anton From ch-tbnl at bobobeach.com Sat Jul 19 20:40:20 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Sat, 19 Jul 2008 13:40:20 -0700 Subject: [hunchentoot-devel] hunchentoot-cgi and the new hunchentoot regime In-Reply-To: <487709C9.70708@bobobeach.com> References: <487709C9.70708@bobobeach.com> Message-ID: <2350497D-28DA-4D3D-85EE-D51688781AE1@bobobeach.com> So... any input/suggestions on how to hack start-output to deal with CGI-style content? thanks, Cyrus On Jul 11, 2008, at 12:20 AM, Cyrus Harmon wrote: > So... I'm trying to convert my hunchentoot-cgi over to the new > hunchentoot and running into some problems. My old approach was to do: > > (progn > (let* ((return-code (tbnl::return-code)) > (reason-phrase (reason-phrase return-code)) > (first-line > (format nil "HTTP/1.1 ~D ~A" return-code reason- > phrase))) > (write-sequence (map 'list #'char-code first-line) out) > (write-sequence tbnl::+crlf+ out) > (tbnl::maybe-write-to-header-stream first-line)) > (setf tbnl::*headers-sent* t) > (setf (tbnl::content-type) nil) > (sb-ext::run-program path nil :output out :environment env) > nil) > > > but this doesn't seem to work anymore. My new approach is to try to > use send-headers, but with some hackery to make it optionally more > cgi-friendly: > Index: headers.lisp > =================================================================== > --- headers.lisp (revision 3423) > +++ headers.lisp (working copy) > @@ -70,6 +70,8 @@ > (:method (key value) > (write-header-line key (princ-to-string value)))) > +(defparameter *cgi-hack* nil) > + > (defun start-output (&key (content nil content-provided-p) > (request *request*)) > "Sends all headers and maybe the content body to > @@ -84,7 +86,8 @@ > ;; Read post data to clear stream - Force binary mode to avoid > OCTETS-TO-STRING overhead. > (raw-post-data :force-binary t) > (let* ((return-code (return-code)) > - (chunkedp (and (server-output-chunking-p *server*) > + (chunkedp (and (not *cgi-hack*) > + (server-output-chunking-p *server*) > (eq (server-protocol request) :http/1.1) > ;; only turn chunking on if the content > ;; length is unknown at this point... > @@ -196,12 +199,14 @@ > ;; write all headers from the REPLY object > (loop for (key . value) in (headers-out) > when value > - do (write-header-line (as-capitalized-string key) value)) > + do (unless (and *cgi-hack* (equal key :content-type)) > + (write-header-line (as-capitalized-string key) value))) > ;; now the cookies > (loop for (nil . cookie) in (cookies-out) > do (write-header-line "Set-Cookie" (stringify-cookie cookie))) > ;; all headers sent > - (write-sequence +crlf+ *hunchentoot-stream*) > + (unless *cgi-hack* > + (write-sequence +crlf+ *hunchentoot-stream*)) > (maybe-write-to-header-stream "") > ;; access log message > (when-let (access-logger (server-access-logger *server*)) > > > > The motivation for this hack being that the CGI script wants to send > the content-type header, so we can't finish the headers here when > running a CGI script. > > Then I can do: > > (let* ((tbnl::*cgi-hack* t) (stream (flexi- > streams:make-flexi-stream > (tbnl:send-headers) > :external-format tbnl::+latin-1+))) > (sb-ext::run-program path nil :output stream :environment env)) > > > and this sort of works, but, 1) it's kind of a hack and 2) it either > exacerbates the timeout situation or there's some other problem > where the first request is handled promptly, but subsequent requests > to 10 seconds or so while something times out. Not sure why this > would be. > > any thoughts on a good way to handle this? > > thanks, > > Cyrus > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From edi at agharta.de Sat Jul 19 21:17:26 2008 From: edi at agharta.de (Edi Weitz) Date: Sat, 19 Jul 2008 23:17:26 +0200 Subject: [hunchentoot-devel] hunchentoot-cgi and the new hunchentoot regime In-Reply-To: <2350497D-28DA-4D3D-85EE-D51688781AE1@bobobeach.com> (Cyrus Harmon's message of "Sat, 19 Jul 2008 13:40:20 -0700") References: <487709C9.70708@bobobeach.com> <2350497D-28DA-4D3D-85EE-D51688781AE1@bobobeach.com> Message-ID: On Sat, 19 Jul 2008 13:40:20 -0700, Cyrus Harmon wrote: > So... any input/suggestions on how to hack start-output to deal with > CGI-style content? Hi Cyrus, Sorry, too busy right now to give a good reply. Otherwise I would have done so already. My very general answer would be that I'd be very happy if we could find a clean (for some value of "clean) solution which doesn't involve "hacks" and/or :: access. More later (I don't know when, though), Edi. From ch-tbnl at bobobeach.com Mon Jul 21 04:40:42 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Sun, 20 Jul 2008 21:40:42 -0700 Subject: [hunchentoot-devel] hunchentoot-cgi and the new hunchentoot regime In-Reply-To: References: <487709C9.70708@bobobeach.com> <2350497D-28DA-4D3D-85EE-D51688781AE1@bobobeach.com> Message-ID: <4FC7D41A-266C-481E-BD98-76D496F9CC9D@bobobeach.com> well, one easy thing to do is to rename *cgi-hack* to *start-output- send-content-type-and-crlf*, and export it. That would remove the "hack" name and the :: access :) Cyrus On Jul 19, 2008, at 2:17 PM, Edi Weitz wrote: > On Sat, 19 Jul 2008 13:40:20 -0700, Cyrus Harmon > wrote: > >> So... any input/suggestions on how to hack start-output to deal with >> CGI-style content? > > Hi Cyrus, > > Sorry, too busy right now to give a good reply. Otherwise I would > have done so already. > > My very general answer would be that I'd be very happy if we could > find a clean (for some value of "clean) solution which doesn't involve > "hacks" and/or :: access. > > More later (I don't know when, though), > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans at huebner.org Mon Jul 21 05:54:51 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 21 Jul 2008 07:54:51 +0200 Subject: [hunchentoot-devel] hunchentoot-cgi and the new hunchentoot regime In-Reply-To: <4FC7D41A-266C-481E-BD98-76D496F9CC9D@bobobeach.com> References: <487709C9.70708@bobobeach.com> <2350497D-28DA-4D3D-85EE-D51688781AE1@bobobeach.com> <4FC7D41A-266C-481E-BD98-76D496F9CC9D@bobobeach.com> Message-ID: On Mon, Jul 21, 2008 at 06:40, Cyrus Harmon wrote: > well, one easy thing to do is to rename *cgi-hack* to > *start-output-send-content-type-and-crlf*, and export it. That would remove > the "hack" name and the :: access :) Why not make the flag to suppress sending the content type and terminating the header be an argument to START-OUTPUT? I don't think that adding more special variables for no good reason would be so nice. It may just be me, though. -Hans From edi at agharta.de Mon Jul 21 06:44:41 2008 From: edi at agharta.de (Edi Weitz) Date: Mon, 21 Jul 2008 08:44:41 +0200 Subject: [hunchentoot-devel] hunchentoot-cgi and the new hunchentoot regime In-Reply-To: (Hans =?iso-8859-1?q?H=FCbner's?= message of "Mon, 21 Jul 2008 07:54:51 +0200") References: <487709C9.70708@bobobeach.com> <2350497D-28DA-4D3D-85EE-D51688781AE1@bobobeach.com> <4FC7D41A-266C-481E-BD98-76D496F9CC9D@bobobeach.com> Message-ID: On Mon, 21 Jul 2008 07:54:51 +0200, "Hans H?bner" wrote: > Why not make the flag to suppress sending the content type and > terminating the header be an argument to START-OUTPUT? I don't > think that adding more special variables for no good reason would be > so nice. It may just be me, though. Fine with me. What's so special about the content type, though? Do you actually want /any/ headers to be sent or any processing to be done? From jaap at streamtech.nl Mon Jul 21 18:54:41 2008 From: jaap at streamtech.nl (Jaap de Heer) Date: Mon, 21 Jul 2008 20:54:41 +0200 Subject: [hunchentoot-devel] multiple POST/GET values Message-ID: <20080721185441.GI14510@c3po.streamtech.nl> Howdy, I ran into trouble with Hunchentoot trying to process the result of a form containing a select multiple: The user can select both foo and bar, which results in both being submitted. In the POST request, this looks something like: "other-field-1=x&foo-or-bar=foo&foo-or-bar=bar&other-field-2=x" Hunchentoot will pick up on only one of them, i.e. (get-post-parameter "foo-or-bar") will be either "foo" or "bar" but not both; it should be both. I've baked a patch for this that will make (get-post-parameter) et al return a list containing all submitted values for this field, if there is more than 1 value; otherwise, it just returns the string as usual. My Lisp fu is limited, and this is only one of a few possible solutions, so feel free to write a better one ;-) BTW. I suppose the same problem and fix applies for multiple checkboxes with the same names, and (though this may be invalid) even multiple fields with the same name. Cheers, Jaap --- util.lisp.org 2008-07-21 20:29:31.000000000 +0200 +++ util.lisp 2008-07-21 20:29:57.000000000 +0200 @@ -168,6 +168,25 @@ (loop for code across (md5:md5sum-sequence string) do (format s "~2,'0x" code)))) +(defun group-by (lst &key (key #'identity) (test #'eq)) + "Transform a sorted list into a list of lists, grouping together elements with equal key." + (labels ((lp (lst result current-group) + (cond ((null lst) (nreverse (if (null current-group) + result + (cons (nreverse current-group) result)))) + ((or (null current-group) + (funcall test + (funcall key (first lst)) + (funcall key (first current-group)))) + (lp (rest lst) + result + (cons (first lst) current-group))) + (t + (lp (rest lst) + (cons (nreverse current-group) result) + (list (first lst))))))) + (lp lst nil nil))) + (defun escape-for-html (string) "Escapes the characters #\\<, #\\>, #\\', #\\\", and #\\& for HTML output." (with-output-to-string (out) @@ -281,12 +300,18 @@ &optional (external-format *hunchentoot-default-external-format*)) "Converts a list FORM-URL-ENCODED-LIST of name/value pairs into an alist. Both names and values are url-decoded while doing this." - (mapcar #'(lambda (entry) - (destructuring-bind (name &optional value) - (split "=" entry :limit 2) - (cons (string-trim " " (url-decode name external-format)) - (url-decode (or value "") external-format)))) - form-url-encoded-list)) + (mapcar (lambda (x) (cons (caar x) + (if (> (length x) 1) + (mapcar #'cdr x) + (cdar x)))) + (group-by (sort (mapcar #'(lambda (entry) + (destructuring-bind (name &optional value) + (split "=" entry :limit 2) + (cons (string-trim " " (url-decode name external-format)) + (url-decode (or value "") external-format)))) + form-url-encoded-list) + #'string< :key #'car) + :key #'car :test #'equal))) (defun url-encode (string &optional (external-format *hunchentoot-default-external-format*)) "URL-encodes a string using the external format EXTERNAL-FORMAT." From xach at xach.com Mon Jul 21 19:04:14 2008 From: xach at xach.com (Zach Beane) Date: Mon, 21 Jul 2008 15:04:14 -0400 Subject: [hunchentoot-devel] multiple POST/GET values In-Reply-To: <20080721185441.GI14510@c3po.streamtech.nl> References: <20080721185441.GI14510@c3po.streamtech.nl> Message-ID: <20080721190414.GD2334@xach.com> On Mon, Jul 21, 2008 at 08:54:41PM +0200, Jaap de Heer wrote: > Howdy, > > I ran into trouble with Hunchentoot trying to process the result > of a form containing a select multiple: > > > The user can select both foo and bar, which results in both being > submitted. > In the POST request, this looks something like: > "other-field-1=x&foo-or-bar=foo&foo-or-bar=bar&other-field-2=x" > > Hunchentoot will pick up on only one of them, i.e. > (get-post-parameter "foo-or-bar") will be either "foo" or > "bar" but not both; it should be both. I disagree (though I'm not sure exactly what you mean by GET-POST-PARAMETER, which isn't a part of Hunchentoot I've ever seen). If you need multiple parameter values for a given name, you can pick them out of the POST-PARAMETERS alist easily enough: (defun post-parameters (name) (let ((alist (tbnl:post-parameters))) (loop for ((key . value)) on alist when (string= key name) collect value))) Zach From xach at xach.com Mon Jul 21 19:10:42 2008 From: xach at xach.com (Zach Beane) Date: Mon, 21 Jul 2008 15:10:42 -0400 Subject: [hunchentoot-devel] multiple POST/GET values In-Reply-To: <20080721190414.GD2334@xach.com> References: <20080721185441.GI14510@c3po.streamtech.nl> <20080721190414.GD2334@xach.com> Message-ID: <20080721191042.GE2334@xach.com> On Mon, Jul 21, 2008 at 03:04:14PM -0400, Zach Beane wrote: > (defun post-parameters (name) > (let ((alist (tbnl:post-parameters))) > (loop for ((key . value)) on alist > when (string= key name) collect value))) Oops. I wrote and tested this function in a package that doesn't :use the hunchentoot package. A better name might be POST-PARAMETER-LIST or something. Zach From jaap at streamtech.nl Mon Jul 21 19:17:33 2008 From: jaap at streamtech.nl (Jaap de Heer) Date: Mon, 21 Jul 2008 21:17:33 +0200 Subject: [hunchentoot-devel] multiple POST/GET values In-Reply-To: <20080721190414.GD2334@xach.com> References: <20080721185441.GI14510@c3po.streamtech.nl> <20080721190414.GD2334@xach.com> Message-ID: <20080721191733.GQ14510@c3po.streamtech.nl> On Mon, Jul 21, 2008 at 03:04:14PM -0400, Zach Beane wrote: > > Hunchentoot will pick up on only one of them, i.e. > > (get-post-parameter "foo-or-bar") will be either "foo" or > > "bar" but not both; it should be both. > > I disagree (though I'm not sure exactly what you mean by > GET-POST-PARAMETER, which isn't a part of Hunchentoot I've ever > seen). If you need multiple parameter values for a given name, you can > pick them out of the POST-PARAMETERS alist easily enough: > > (defun post-parameters (name) > (let ((alist (tbnl:post-parameters))) > (loop for ((key . value)) on alist > when (string= key name) collect value))) Woops, I meant (post-parameter) of course. But yes, that makes more sense. Thanks, Jaap From lispercat at gmail.com Mon Jul 21 20:10:29 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Mon, 21 Jul 2008 16:10:29 -0400 Subject: [hunchentoot-devel] redirect method works in IE but not in Firefox Message-ID: When I use redirect method at the end of ht handler (which I used for a long time before) suddenly it stopped working in Firefox (though it works in IE). Firefox doesn't receive the http response with code 302. It started to happen after I added quite a few more drakma's http-requests with cookies in the handler. Any idea why it might be happening? Thank you, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiuma72 at gmail.com Mon Jul 21 21:00:23 2008 From: kiuma72 at gmail.com (Andrea Chiumenti) Date: Mon, 21 Jul 2008 21:00:23 +0000 Subject: [hunchentoot-devel] multiple POST/GET values In-Reply-To: <20080721191733.GQ14510@c3po.streamtech.nl> References: <20080721185441.GI14510@c3po.streamtech.nl> <20080721190414.GD2334@xach.com> <20080721191733.GQ14510@c3po.streamtech.nl> Message-ID: <4d3bc9370807211400y299e5e4rb6a0f0da3ede1099@mail.gmail.com> Hi, see defmethods page-req-parameter and page-request-parameters here http://common-lisp.net/websvn/filedetails.php?repname=claw&path=%2Ftrunk%2Fmain%2Fclaw-core%2Fsrc%2Ftags.lisp&rev=0&sc=0 ps. (claw-post-parameters) (claw-get-parameters) are the same of (post-parameters) (get-parameters). cheers kiuma On Mon, Jul 21, 2008 at 7:17 PM, Jaap de Heer wrote: > On Mon, Jul 21, 2008 at 03:04:14PM -0400, Zach Beane wrote: >> > Hunchentoot will pick up on only one of them, i.e. >> > (get-post-parameter "foo-or-bar") will be either "foo" or >> > "bar" but not both; it should be both. >> >> I disagree (though I'm not sure exactly what you mean by >> GET-POST-PARAMETER, which isn't a part of Hunchentoot I've ever >> seen). If you need multiple parameter values for a given name, you can >> pick them out of the POST-PARAMETERS alist easily enough: >> >> (defun post-parameters (name) >> (let ((alist (tbnl:post-parameters))) >> (loop for ((key . value)) on alist >> when (string= key name) collect value))) > > Woops, I meant (post-parameter) of course. > But yes, that makes more sense. > > Thanks, > > Jaap > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From ch-tbnl at bobobeach.com Tue Jul 22 02:04:10 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 21 Jul 2008 19:04:10 -0700 Subject: [hunchentoot-devel] hunchentoot-cgi and the new hunchentoot regime In-Reply-To: References: <487709C9.70708@bobobeach.com> <2350497D-28DA-4D3D-85EE-D51688781AE1@bobobeach.com> <4FC7D41A-266C-481E-BD98-76D496F9CC9D@bobobeach.com> Message-ID: Falling squarely in the more than one way to skin a cat, perhaps it's easier to just read off the CGI headers and DTRT WRT to those headers and then send the output of the CGI to the tbnl output-stream. (let* ((process (sb-ext::run-program path nil :output :stream :environment env)) (in (sb-ext:process-output process))) (let ((headers (loop for line = (chunga:read-line* in) until (equal line "") collect (destructuring-bind (key val) (ppcre:split ": " line) (cons (chunga:as-keyword key) val))))) (let ((type-cons (assoc :content-type headers))) (when type-cons (setf (tbnl:content-type) (cdr type-cons))))) (let ((out (flexi-streams:make-flexi-stream (tbnl:send-headers) :external-format tbnl::+latin-1+))) (do ((c (read-char in) (read-char in))) ((eq c 'eof)) (write-char c out)))) This works well enough for the git CGI interface to sit behind (an unhacked) hunchentoot and hunchentoot-cgi as can be seen here: http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-cgi.git thanks for prodding me to think about this some more... cyrus On Jul 20, 2008, at 11:44 PM, Edi Weitz wrote: > On Mon, 21 Jul 2008 07:54:51 +0200, "Hans H?bner" > wrote: > >> Why not make the flag to suppress sending the content type and >> terminating the header be an argument to START-OUTPUT? I don't >> think that adding more special variables for no good reason would be >> so nice. It may just be me, though. > > Fine with me. > > What's so special about the content type, though? Do you actually > want /any/ headers to be sent or any processing to be done? > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans at huebner.org Tue Jul 22 05:33:07 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 22 Jul 2008 07:33:07 +0200 Subject: [hunchentoot-devel] hunchentoot-cgi and the new hunchentoot regime In-Reply-To: References: <487709C9.70708@bobobeach.com> <2350497D-28DA-4D3D-85EE-D51688781AE1@bobobeach.com> <4FC7D41A-266C-481E-BD98-76D496F9CC9D@bobobeach.com> Message-ID: Cyrus, in the code sample below, is it your intention to discard all headers sent by the CGI program? If not, I'd suggest that you just add them all to the list of outgoing headers. Also, you may want to use a COPY-STREAM function (like http://bknr.net/trac/browser/trunk/bknr/datastore/src/utils/utils.lisp#L189) instead of copying the data character wise for efficiency and readability. (let* ((process (sb-ext::run-program path nil :output :stream :environment env)) (in (sb-ext:process-output process))) (loop for line = (chung:read-line* in) until (equal line "") do (destructuring-bind (key val) (ppcre:split ":\\s*" line) (setf (hunchentoot:header-out key) val))) (copy-stream in (flexi-streams:make-flexi-stream (tbnl:send-headers) :external-format tbnl::+latin-1+) :element-type 'character)) -Hans On Tue, Jul 22, 2008 at 04:04, Cyrus Harmon wrote: > Falling squarely in the more than one way to skin a cat, perhaps it's easier > to just read off the CGI headers and DTRT WRT to those headers and then send > the output of the CGI to the tbnl output-stream. > > (let* ((process (sb-ext::run-program path nil > :output :stream > :environment env)) > (in (sb-ext:process-output process))) > (let ((headers > (loop for line = (chunga:read-line* in) > until (equal line "") > collect (destructuring-bind > (key val) > (ppcre:split ": " line) > (cons (chunga:as-keyword key) val))))) > (let ((type-cons (assoc :content-type headers))) > (when type-cons > (setf (tbnl:content-type) > (cdr type-cons))))) > (let ((out (flexi-streams:make-flexi-stream > (tbnl:send-headers) > :external-format tbnl::+latin-1+))) > (do ((c (read-char in) (read-char in))) > ((eq c 'eof)) > (write-char c out)))) > > This works well enough for the git CGI interface to sit behind (an unhacked) > hunchentoot and hunchentoot-cgi as can be seen here: > > http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-cgi.git > > thanks for prodding me to think about this some more... > > cyrus > > > On Jul 20, 2008, at 11:44 PM, Edi Weitz wrote: > >> On Mon, 21 Jul 2008 07:54:51 +0200, "Hans H?bner" >> wrote: >> >>> Why not make the flag to suppress sending the content type and >>> terminating the header be an argument to START-OUTPUT? I don't >>> think that adding more special variables for no good reason would be >>> so nice. It may just be me, though. >> >> Fine with me. >> >> What's so special about the content type, though? Do you actually >> want /any/ headers to be sent or any processing to be done? >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From hans at huebner.org Tue Jul 22 09:29:30 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 22 Jul 2008 11:29:30 +0200 Subject: [hunchentoot-devel] redirect method works in IE but not in Firefox In-Reply-To: References: Message-ID: Andrew, On Mon, Jul 21, 2008 at 22:10, Andrei Stebakov wrote: > When I use redirect method at the end of ht handler (which I used for a long > time before) suddenly it stopped working in Firefox (though it works in IE). > Firefox doesn't receive the http response with code 302. Can you supply us with an isolated test case to reproduce the problem? Also let us know what platform you are using. Thanks, Hans From edi at agharta.de Tue Jul 22 11:11:23 2008 From: edi at agharta.de (Edi Weitz) Date: Tue, 22 Jul 2008 13:11:23 +0200 Subject: [hunchentoot-devel] redirect method works in IE but not in Firefox In-Reply-To: (Andrei Stebakov's message of "Mon, 21 Jul 2008 16:10:29 -0400") References: Message-ID: On Mon, 21 Jul 2008 16:10:29 -0400, "Andrei Stebakov" wrote: > When I use redirect method at the end of ht handler (which I used > for a long time before) suddenly it stopped working in Firefox > (though it works in IE). Firefox doesn't receive the http response > with code 302. It started to happen after I added quite a few more > drakma's http-requests with cookies in the handler. I fail to imagine how this could relate to Drakma. As Hans said, is there a way for us to reproduce this? From lispercat at gmail.com Tue Jul 22 14:23:30 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 22 Jul 2008 10:23:30 -0400 Subject: [hunchentoot-devel] redirect method works in IE but not in Firefox In-Reply-To: References: Message-ID: I wish I could isolate it. I started to experiment with drakma requests and I changed methods from :head to :get and it seemed to fix the problem. On Tue, Jul 22, 2008 at 7:11 AM, Edi Weitz wrote: > On Mon, 21 Jul 2008 16:10:29 -0400, "Andrei Stebakov" > wrote: > > > When I use redirect method at the end of ht handler (which I used > > for a long time before) suddenly it stopped working in Firefox > > (though it works in IE). Firefox doesn't receive the http response > > with code 302. It started to happen after I added quite a few more > > drakma's http-requests with cookies in the handler. > > I fail to imagine how this could relate to Drakma. As Hans said, is > there a way for us to reproduce this? > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch-tbnl at bobobeach.com Tue Jul 22 15:47:56 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Tue, 22 Jul 2008 08:47:56 -0700 Subject: [hunchentoot-devel] hunchentoot-cgi and the new hunchentoot regime In-Reply-To: References: <487709C9.70708@bobobeach.com> <2350497D-28DA-4D3D-85EE-D51688781AE1@bobobeach.com> <4FC7D41A-266C-481E-BD98-76D496F9CC9D@bobobeach.com> Message-ID: Hans, Yes, my original code was a "proof of concept" that I didn't need to hack up send-output to make this is work. Your version is much better. thanks! Cyrus On Jul 21, 2008, at 10:33 PM, Hans H?bner wrote: > Cyrus, > > in the code sample below, is it your intention to discard all headers > sent by the CGI program? If not, I'd suggest that you just add them > all to the list of outgoing headers. Also, you may want to use a > COPY-STREAM function (like > http://bknr.net/trac/browser/trunk/bknr/datastore/src/utils/utils.lisp#L189) > instead of copying the data character wise for efficiency and > readability. > > (let* ((process (sb-ext::run-program path nil > :output :stream > :environment env)) > (in (sb-ext:process-output process))) > (loop for line = (chung:read-line* in) > until (equal line "") > do (destructuring-bind (key val) > (ppcre:split ":\\s*" line) > (setf (hunchentoot:header-out key) val))) > (copy-stream in (flexi-streams:make-flexi-stream > (tbnl:send-headers) > :external-format tbnl::+latin-1+) > :element-type 'character)) > > -Hans > > On Tue, Jul 22, 2008 at 04:04, Cyrus Harmon > wrote: >> Falling squarely in the more than one way to skin a cat, perhaps >> it's easier >> to just read off the CGI headers and DTRT WRT to those headers and >> then send >> the output of the CGI to the tbnl output-stream. >> >> (let* ((process (sb-ext::run-program path nil >> :output :stream >> :environment env)) >> (in (sb-ext:process-output process))) >> (let ((headers >> (loop for line = (chunga:read-line* in) >> until (equal line "") >> collect (destructuring-bind >> (key val) >> (ppcre:split ": " line) >> (cons (chunga:as-keyword key) val))))) >> (let ((type-cons (assoc :content-type headers))) >> (when type-cons >> (setf (tbnl:content-type) >> (cdr type-cons))))) >> (let ((out (flexi-streams:make-flexi-stream >> (tbnl:send-headers) >> :external-format tbnl::+latin-1+))) >> (do ((c (read-char in) (read-char in))) >> ((eq c 'eof)) >> (write-char c out)))) >> >> This works well enough for the git CGI interface to sit behind (an >> unhacked) >> hunchentoot and hunchentoot-cgi as can be seen here: >> >> http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-cgi.git >> >> thanks for prodding me to think about this some more... >> >> cyrus >> >> >> On Jul 20, 2008, at 11:44 PM, Edi Weitz wrote: >> >>> On Mon, 21 Jul 2008 07:54:51 +0200, "Hans H?bner" >>> wrote: >>> >>>> Why not make the flag to suppress sending the content type and >>>> terminating the header be an argument to START-OUTPUT? I don't >>>> think that adding more special variables for no good reason would >>>> be >>>> so nice. It may just be me, though. >>> >>> Fine with me. >>> >>> What's so special about the content type, though? Do you actually >>> want /any/ headers to be sent or any processing to be done? >>> _______________________________________________ >>> tbnl-devel site list >>> tbnl-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From lispercat at gmail.com Thu Jul 24 17:27:19 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Thu, 24 Jul 2008 13:27:19 -0400 Subject: [hunchentoot-devel] Redirecting preserving the session? Message-ID: When I use redirect method it redirects to a new url and in the handler for the url I have no way of knowing the session of the url from where it was redirected. How can I send cookies along with redirecting to a new url? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Thu Jul 24 19:34:16 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 24 Jul 2008 21:34:16 +0200 Subject: [hunchentoot-devel] Redirecting preserving the session? In-Reply-To: References: Message-ID: Andrei, I am not sure I understand: Are you redirecting the request to the same web server, or to a different one? If you redirecting to the same server, any cookie you might have set before should be presented by the browser to the new URL. If you're redirecting to a different server, you can't set cookies to be presented to that different server. Please try to give us more information. -Hans On Thu, Jul 24, 2008 at 19:27, Andrei Stebakov wrote: > When I use redirect method it redirects to a new url and in the handler for > the url I have no way of knowing the session of the url from where it was > redirected. > How can I send cookies along with redirecting to a new url? > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From lispercat at gmail.com Thu Jul 24 19:55:12 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Thu, 24 Jul 2008 15:55:12 -0400 Subject: [hunchentoot-devel] Redirecting preserving the session? In-Reply-To: References: Message-ID: I am redirecting to the same server. So you are saying that the cookie should be there, I'll try to access them. I was just trying to refer to the session but it was empty. I was just trying to keep session alive even between redirects just like I can keep it alive when requests from different urls come to the same server from a user. I wonder if it's possible for redirects. On Thu, Jul 24, 2008 at 3:34 PM, Hans H?bner wrote: > Andrei, > > I am not sure I understand: Are you redirecting the request to the > same web server, or to a different one? If you redirecting to the > same server, any cookie you might have set before should be presented > by the browser to the new URL. If you're redirecting to a different > server, you can't set cookies to be presented to that different > server. > > Please try to give us more information. > > -Hans > > On Thu, Jul 24, 2008 at 19:27, Andrei Stebakov > wrote: > > When I use redirect method it redirects to a new url and in the handler > for > > the url I have no way of knowing the session of the url from where it was > > redirected. > > How can I send cookies along with redirecting to a new url? > > > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Thu Jul 24 20:04:32 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 24 Jul 2008 22:04:32 +0200 Subject: [hunchentoot-devel] Redirecting preserving the session? In-Reply-To: References: Message-ID: Andrei, Cookies are set in the browser by the Set-Cookie header, and the redirect itself has no influence on what cookies the browser sends to the server. I would recommend that you set HUNCHENTOOT:*HEADER-STREAM* to *STANDARD-OUTPUT* and observer when and if the session cookie gets set and is sent back. The session cookie is set by Hunchentoot when START-SESSION is called. Using the header debug output, you should be able to trace what's going on and maybe give us a more detailed description of what your problem is. -Hans On Thu, Jul 24, 2008 at 21:55, Andrei Stebakov wrote: > I am redirecting to the same server. So you are saying that the cookie > should be there, I'll try to access them. > I was just trying to refer to the session but it was empty. I was just > trying to keep session alive even between redirects just like I can keep it > alive when requests from different urls come to the same server from a user. > I wonder if it's possible for redirects. > > > On Thu, Jul 24, 2008 at 3:34 PM, Hans H?bner wrote: >> >> Andrei, >> >> I am not sure I understand: Are you redirecting the request to the >> same web server, or to a different one? If you redirecting to the >> same server, any cookie you might have set before should be presented >> by the browser to the new URL. If you're redirecting to a different >> server, you can't set cookies to be presented to that different >> server. >> >> Please try to give us more information. >> >> -Hans >> >> On Thu, Jul 24, 2008 at 19:27, Andrei Stebakov >> wrote: >> > When I use redirect method it redirects to a new url and in the handler >> > for >> > the url I have no way of knowing the session of the url from where it >> > was >> > redirected. >> > How can I send cookies along with redirecting to a new url? >> > >> > >> > _______________________________________________ >> > tbnl-devel site list >> > tbnl-devel at common-lisp.net >> > http://common-lisp.net/mailman/listinfo/tbnl-devel >> > >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From lispercat at gmail.com Fri Jul 25 15:02:22 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Fri, 25 Jul 2008 11:02:22 -0400 Subject: [hunchentoot-devel] Hunchentoot behind apache http proxy (performance) Message-ID: The moment came when I had to move all of my site from being partially static http web pages to pages generated (or served from cached files) by Hunchentoot. The overall performance noticeably degraded in terms of response time. Even in cases when HT does nothing but serves a static file from its cache the response time increased from 0.3 sec to 1.5 sec (tested with httperf). I am running Apache 2 on Ubuntu (everything latest) with sbcl 1.0.18. I understand that when ht running behind the proxy the response time should increase. I wonder what can I do to optimize. Is it time to run HT as a standalone server? I still have a bunch of pages that I need to serve statically and lately my sbcl had problems with GC so it crashes time after time from heap exhaustion, so I am a bit uncomfortable to switch completely to Hunchentoot. I wonder how do you guys solve those problems? Thank you, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Fri Jul 25 16:43:49 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 25 Jul 2008 18:43:49 +0200 Subject: [hunchentoot-devel] Hunchentoot behind apache http proxy (performance) In-Reply-To: References: Message-ID: I wrote a blog entry about how we try to reduce the load on our (Hunchentoot) backend and whet we want in a front end. See http://netzhansa.blogspot.com/2008/07/building-load-resilient-web-servers.html - Comments gladly discussed here, too. -Hans On Fri, Jul 25, 2008 at 17:02, Andrei Stebakov wrote: > The moment came when I had to move all of my site from being partially > static http web pages to pages generated (or served from cached files) by > Hunchentoot. > The overall performance noticeably degraded in terms of response time. Even > in cases when HT does nothing but serves a static file from its cache the > response time increased from 0.3 sec to 1.5 sec (tested with httperf). > I am running Apache 2 on Ubuntu (everything latest) with sbcl 1.0.18. > I understand that when ht running behind the proxy the response time should > increase. I wonder what can I do to optimize. > Is it time to run HT as a standalone server? I still have a bunch of pages > that I need to serve statically and lately my sbcl had problems with GC so > it crashes time after time from heap exhaustion, so I am a bit > uncomfortable to switch completely to Hunchentoot. > I wonder how do you guys solve those problems? > > Thank you, > Andrew > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From lispercat at gmail.com Fri Jul 25 17:39:07 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Fri, 25 Jul 2008 13:39:07 -0400 Subject: [hunchentoot-devel] Hunchentoot behind apache http proxy (performance) In-Reply-To: References: Message-ID: I've heard nice things about nginx (reverse proxy as well), I gave it a try but it had different rewrite rules from Apache and doesn't have log rotation mechanism. I am back to Apache as I didn't have time to play with it longer. Back to Hunchentoot. I couldn't find how "Accept-Encoding: gzip, deflate" request is handled? When the client sends this header, HT doesn't compress the content responding with "Content-Encoding: gzip", is there a way to enable it to compress some text or CSS content? On Fri, Jul 25, 2008 at 12:43 PM, Hans H?bner wrote: > I wrote a blog entry about how we try to reduce the load on our > (Hunchentoot) backend and whet we want in a front end. See > > http://netzhansa.blogspot.com/2008/07/building-load-resilient-web-servers.html > - Comments gladly discussed here, too. > > -Hans > > On Fri, Jul 25, 2008 at 17:02, Andrei Stebakov > wrote: > > The moment came when I had to move all of my site from being partially > > static http web pages to pages generated (or served from cached files) by > > Hunchentoot. > > The overall performance noticeably degraded in terms of response time. > Even > > in cases when HT does nothing but serves a static file from its cache the > > response time increased from 0.3 sec to 1.5 sec (tested with httperf). > > I am running Apache 2 on Ubuntu (everything latest) with sbcl 1.0.18. > > I understand that when ht running behind the proxy the response time > should > > increase. I wonder what can I do to optimize. > > Is it time to run HT as a standalone server? I still have a bunch of > pages > > that I need to serve statically and lately my sbcl had problems with GC > so > > it crashes time after time from heap exhaustion, so I am a bit > > uncomfortable to switch completely to Hunchentoot. > > I wonder how do you guys solve those problems? > > > > Thank you, > > Andrew > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Fri Jul 25 19:05:41 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 25 Jul 2008 21:05:41 +0200 Subject: [hunchentoot-devel] Hunchentoot behind apache http proxy (performance) In-Reply-To: References: Message-ID: On Fri, Jul 25, 2008 at 19:39, Andrei Stebakov wrote: > I've heard nice things about nginx (reverse proxy as well), I gave it a try > but it had different rewrite rules from Apache and doesn't have log rotation > mechanism. The most important drawback of nginx is that it does not do any caching, so it really can';t help with the performance improvement strategies that I'd be interested in. In general, I try to set up things in a manner that only those requests hit my Hunchentoot backend that really create dynamic content which is different from other requests. Everything else is handled by the frontend and served from its cache. > Back to Hunchentoot. I couldn't find how "Accept-Encoding: gzip, deflate" > request is handled? When the client sends this header, HT doesn't compress > the content responding with "Content-Encoding: gzip", is there a way to > enable it to compress some text or CSS content? No. -Hans From rflug05 at gmail.com Thu Jul 31 01:58:06 2008 From: rflug05 at gmail.com (Nick Allen) Date: Thu, 31 Jul 2008 03:58:06 +0200 Subject: [hunchentoot-devel] with-recursive-lock-held Message-ID: Hello! Is the "ediware" location of the hunchentoot source the recommended version for deployment? or should we be using the tarball linked off the documentation or the "hans" version? I'm wondering because WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of "lispworks.lisp", which seems to have introducing some bugs, which seems to me to suggests to me that the "ediware" repo is either out of date or too bleeding edge... take care Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Thu Jul 31 05:09:00 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 31 Jul 2008 07:09:00 +0200 Subject: [hunchentoot-devel] with-recursive-lock-held In-Reply-To: References: Message-ID: Hi Nick, thank you for reporting a problem - Can you provide me with details on how the removal of WITH-RECURSIVE-LOCK breaks Hunchentoot for Lispworks? I have removed it because I believed that there is no code path that could be to recursive locking, but I could have been missing something. In general, the Subversion repository is less stable than Edi's releases and we are planning to make a proper release, yet I can't make any promises. Thanks, Hans On Thu, Jul 31, 2008 at 03:58, Nick Allen wrote: > Hello! > Is the "ediware" location of the hunchentoot source the recommended version > for deployment? or should we be using the tarball linked off the > documentation or the "hans" version? I'm wondering because > WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of "lispworks.lisp", > which seems to have introducing some bugs, which seems to me to suggests to > me that the "ediware" repo is either out of date or too bleeding edge... > take care > Nick > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From rflug05 at gmail.com Thu Jul 31 15:43:44 2008 From: rflug05 at gmail.com (Nick Allen) Date: Thu, 31 Jul 2008 17:43:44 +0200 Subject: [hunchentoot-devel] with-recursive-lock-held In-Reply-To: References: Message-ID: Hello Hans, The specific problem I ran into was a recursive lock error thrown when setting a session value in the same request that starts a session. I'm using rev 3591. here's an example: (defun test-dispatcher (hunchentoot:*request*) (lambda () ;; set the session value FOO to the value of ;; the HTTP get parameter "set-foo", if it ;; exists (let ((set-foo (hunchentoot:get-parameter "set-foo"))) (when set-foo (setf (hunchentoot:session-value 'foo) set-foo))) ;; then return a page that shows the session ;; value FOO (format nil "The foo is ~A" (hunchentoot:session-value 'foo)))) ;; start the server (pushnew 'test-dispatcher hunchentoot:*dispatch-table*) (defvar *test-server* (hunchentoot:start-server :port 2001)) ;; now go to: ;; ;; http://localhost:2001?set-foo=bar ;; ;; it should look like: ;; ;; The Foo is bar ;; ;; but it throws a recursive lock error On Thu, Jul 31, 2008 at 7:09 AM, Hans H?bner wrote: > Hi Nick, > > thank you for reporting a problem - Can you provide me with details on > how the removal of WITH-RECURSIVE-LOCK breaks Hunchentoot for > Lispworks? I have removed it because I believed that there is no code > path that could be to recursive locking, but I could have been missing > something. > > In general, the Subversion repository is less stable than Edi's > releases and we are planning to make a proper release, yet I can't > make any promises. > > Thanks, > Hans > > On Thu, Jul 31, 2008 at 03:58, Nick Allen wrote: > > Hello! > > Is the "ediware" location of the hunchentoot source the recommended > version > > for deployment? or should we be using the tarball linked off the > > documentation or the "hans" version? I'm wondering because > > WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of > "lispworks.lisp", > > which seems to have introducing some bugs, which seems to me to suggests > to > > me that the "ediware" repo is either out of date or too bleeding edge... > > take care > > Nick > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at huebner.org Thu Jul 31 16:03:21 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 31 Jul 2008 18:03:21 +0200 Subject: [hunchentoot-devel] with-recursive-lock-held In-Reply-To: References: Message-ID: Hi Nick, thank you for your detailed report. I think I have fixed the problem, can you svn up and let me know if it works better? If not, I'll hack on it more so that things get back to a good state tonight. Sorry for the glitch. Thanks, Hans On Thu, Jul 31, 2008 at 17:43, Nick Allen wrote: > Hello Hans, > The specific problem I ran into was a recursive lock error thrown when > setting a session value in the same request that starts a session. I'm using > rev 3591. here's an example: > (defun test-dispatcher (hunchentoot:*request*) > (lambda () > ;; set the session value FOO to the value of > ;; the HTTP get parameter "set-foo", if it > ;; exists > (let ((set-foo (hunchentoot:get-parameter "set-foo"))) > (when set-foo > (setf (hunchentoot:session-value 'foo) set-foo))) > ;; then return a page that shows the session > ;; value FOO > (format nil "The foo is ~A" (hunchentoot:session-value 'foo)))) > > ;; start the server > (pushnew 'test-dispatcher hunchentoot:*dispatch-table*) > (defvar *test-server* (hunchentoot:start-server :port 2001)) > ;; now go to: > ;; > ;; http://localhost:2001?set-foo=bar > ;; > ;; it should look like: > ;; > ;; The Foo is bar > ;; > ;; but it throws a recursive lock error > On Thu, Jul 31, 2008 at 7:09 AM, Hans H?bner wrote: >> >> Hi Nick, >> >> thank you for reporting a problem - Can you provide me with details on >> how the removal of WITH-RECURSIVE-LOCK breaks Hunchentoot for >> Lispworks? I have removed it because I believed that there is no code >> path that could be to recursive locking, but I could have been missing >> something. >> >> In general, the Subversion repository is less stable than Edi's >> releases and we are planning to make a proper release, yet I can't >> make any promises. >> >> Thanks, >> Hans >> >> On Thu, Jul 31, 2008 at 03:58, Nick Allen wrote: >> > Hello! >> > Is the "ediware" location of the hunchentoot source the recommended >> > version >> > for deployment? or should we be using the tarball linked off the >> > documentation or the "hans" version? I'm wondering because >> > WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of >> > "lispworks.lisp", >> > which seems to have introducing some bugs, which seems to me to suggests >> > to >> > me that the "ediware" repo is either out of date or too bleeding edge... >> > take care >> > Nick >> > _______________________________________________ >> > tbnl-devel site list >> > tbnl-devel at common-lisp.net >> > http://common-lisp.net/mailman/listinfo/tbnl-devel >> > >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From rflug05 at gmail.com Thu Jul 31 20:41:38 2008 From: rflug05 at gmail.com (Nick Allen) Date: Thu, 31 Jul 2008 22:41:38 +0200 Subject: [hunchentoot-devel] with-recursive-lock-held In-Reply-To: References: Message-ID: Hello, The session value / recursive lock stuff all seems to work as of rev #3712. thanks for the quick response, keep up the good work! Nick On Thu, Jul 31, 2008 at 6:03 PM, Hans H?bner wrote: > Hi Nick, > > thank you for your detailed report. I think I have fixed the problem, > can you svn up and let me know if it works better? If not, I'll hack > on it more so that things get back to a good state tonight. Sorry for > the glitch. > > Thanks, > Hans > > On Thu, Jul 31, 2008 at 17:43, Nick Allen wrote: > > Hello Hans, > > The specific problem I ran into was a recursive lock error thrown when > > setting a session value in the same request that starts a session. I'm > using > > rev 3591. here's an example: > > (defun test-dispatcher (hunchentoot:*request*) > > (lambda () > > ;; set the session value FOO to the value of > > ;; the HTTP get parameter "set-foo", if it > > ;; exists > > (let ((set-foo (hunchentoot:get-parameter "set-foo"))) > > (when set-foo > > (setf (hunchentoot:session-value 'foo) set-foo))) > > ;; then return a page that shows the session > > ;; value FOO > > (format nil "The foo is ~A" (hunchentoot:session-value 'foo)))) > > > > ;; start the server > > (pushnew 'test-dispatcher hunchentoot:*dispatch-table*) > > (defvar *test-server* (hunchentoot:start-server :port 2001)) > > ;; now go to: > > ;; > > ;; http://localhost:2001?set-foo=bar > > ;; > > ;; it should look like: > > ;; > > ;; The Foo is bar > > ;; > > ;; but it throws a recursive lock error > > On Thu, Jul 31, 2008 at 7:09 AM, Hans H?bner wrote: > >> > >> Hi Nick, > >> > >> thank you for reporting a problem - Can you provide me with details on > >> how the removal of WITH-RECURSIVE-LOCK breaks Hunchentoot for > >> Lispworks? I have removed it because I believed that there is no code > >> path that could be to recursive locking, but I could have been missing > >> something. > >> > >> In general, the Subversion repository is less stable than Edi's > >> releases and we are planning to make a proper release, yet I can't > >> make any promises. > >> > >> Thanks, > >> Hans > >> > >> On Thu, Jul 31, 2008 at 03:58, Nick Allen wrote: > >> > Hello! > >> > Is the "ediware" location of the hunchentoot source the recommended > >> > version > >> > for deployment? or should we be using the tarball linked off the > >> > documentation or the "hans" version? I'm wondering because > >> > WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of > >> > "lispworks.lisp", > >> > which seems to have introducing some bugs, which seems to me to > suggests > >> > to > >> > me that the "ediware" repo is either out of date or too bleeding > edge... > >> > take care > >> > Nick > >> > _______________________________________________ > >> > tbnl-devel site list > >> > tbnl-devel at common-lisp.net > >> > http://common-lisp.net/mailman/listinfo/tbnl-devel > >> > > >> _______________________________________________ > >> tbnl-devel site list > >> tbnl-devel at common-lisp.net > >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: