December 2006 - tbnl-devel@common-lisp.net

[hunchentoot-devel] Preferred method for login?
by Jonathon McKitrick 20 Dec '06

20 Dec '06

I was searching the mailing list and ran across a couple of ways to set up authorized handlers. Is there an 'official' or recommended way of doing this that works best in practice? Or is there really no wrong way to do it as long as it works? I just want to separate a group of uri's that should have authorization before they can allow access. Jonathon McKitrick -- My other computer is your Windows box.

1 0

[hunchentoot-devel] Starting a server hangs
by Jonathon McKitrick 20 Dec '06

20 Dec '06

Hi all, I'm experimenting with hunchentoot with a view to porting my web app. I have 0.4.11 running on SBCL-1.0 and Ubuntu Linux. I have a default handler set up, and call: (hunchentoot:start-server :port 8888) and it works fine. However, when I call the above function from inside the startup sequence of the asdf system that loads the app, it hangs. What am I doing wrong here? Jonathon McKitrick -- My other computer is your Windows box.

4 10

[hunchentoot-devel] Other http methods allowed?
by Jonathon McKitrick 19 Dec '06

19 Dec '06

I did not see specifically if the other http methods PUT and DELETE are supported. If not, is it correct to assume they could be easily added? Jonathon McKitrick -- My other computer is your Windows box.

2 3

[hunchentoot-devel] I/O timeout error (SBCL)
by vedm 16 Dec '06

16 Dec '06

When I set *catch-errors-p* to nil I often see this error in the debugger: == I/O timeout reading #<SB-SYS:FD-STREAM for "a constant string" {B3E4CA1}> [Condition of type SB-SYS:IO-TIMEOUT] == even though I still get my pages in the browser. Any idea why this happens? -- vedm

2 5

[hunchentoot-devel] tbnl-worker threads
by quasi 07 Dec '06

07 Dec '06

Hey, We are using Apache+mod_lisp2+TBNL for our website. The load has sorta spiked of late, we serve approx 4-5 concurrent pages (which are heavy, computationally and in size). We are using Allegro CL. The thing observed is that there are about 70-100 tbnl-worker threads which I dont think are doing anything much. There is a limit of 230 threads on the Allegro CL and this 100 threads becomes worrysome. I think they have a timeout and the die eventually, but I wonder at their existance and if they could be made to die an early death (I could give them some cig's but ...). :) BTW is it good time to move from TBNL -> Hunchentoot ? Because it's a live system and 'if it aint broke dont fix it' comes to me mind. Any ideas about the performance etc. ? I did some initial benchmarks and seems to be a tad slower than apache+mod_lisp2+TBNL ... but the benchmarks were not serious. I will do them again. thanks, -- quasi Utopia Unlimited!

2 1

[hunchentoot-devel] Problems with create-folder-dispatcher-and-handler
by Rafał Strzaliński 07 Dec '06

07 Dec '06

Hi, I've tried to serve files from 'public' directory under '/' base URL: (hunchentoot::create-folder-dispatcher-and-handler "/" #p"public/") and always got 403 HTTP error. When I've changed base url to for example '/public/' everything works fine. I've tried to fix it, but i'm don't understand pathnames well :-( Any ideas? IMHO (with-chroot (directory) ...) would be an ideal solution :-) Environment: SBCL 1.0 Debian Etch Hunchentoot 0.4.10 -- Best regards, Rafal Strzalinski (nabla) http://rafal.strzalinski.pl

2 1

[hunchentoot-devel] global dispatch-table
by Cyrus Harmon 05 Dec '06

05 Dec '06

What's the rationale behind a global dispatch table? It seems like it might be nicer to have a per-server dispatch table. I can't imagine that there would be a good reason not have access to the server object when accessing *dispatch-table*, although as currently structured process-request should probably take an additional argument for the server. Thanks, Cyrus

2 2

[hunchentoot-devel] dispatch-table request
by Cyrus Harmon 04 Dec '06

04 Dec '06

Edi, First of all, thanks for hunchentoot! I'm still getting used to it, but it seems great so far. But I do have a request. Would it be possible (and advisable) to extend the dispatch table to provide some metadata for each dispatcher? this could even be done in a backward compatible way by allowing the dispatchers in *dispatch-table* to be conses (or objects of an appropriately defined class) which would be examined as necessary, or just funcalled as they are presently, in the event that the dispatcher is just a lambda. This would facilitate debugging and modifying the dispatch table. Thanks, Cyrus

6 7

Re: [hunchentoot-devel] CMUCL vs SBCL: server speed
by Edi Weitz 04 Dec '06

04 Dec '06

[Please use the mailing list.} On Sun, 3 Dec 2006 14:24:52 -0800, Jeffrey Cunningham <jeffrey(a)cunningham.net> wrote: > Hmmm. That's interesting. I just tried both at once and it killed > CMUCL (running under slime). I guess my unstable collection of CMUCL > + Slime + various CL packages don't all like each other yet. I think one of the links I sent talks about issues with SLIME. I'm sure Google will find something for you, but ISTR that the general wisdom is that these two don't mix well - the guys on the SLIME or CMUCL mailing list will probably know more about it. Cheers, Edi.

1 0

[hunchentoot-devel] CMUCL vs SBCL: server speed
by Jeffrey Cunningham 03 Dec '06

03 Dec '06

I thought I'd share some observations concerning a big difference in server speed I've observered between CMUCL (19d) and SBCL (0.9.18). I've been working on a small website consisting of six or eight pages, each with mixed text and graphics (images from a few k up to 80k) using Hunchentoot as the server. Running it with CMUCL I noticed that the page load times were rather slow (2-5 seconds to all the images) I tried serving all the images out of ram (as in Edi's example), but it really made little differnce. It didn't matter whether I was browsing it via localhost or over the internet - the server was too slow for anything but a testbench. After the problems I had trying to get SSL to work with CMUCL, I decided to get the test site running with SBCL. (I hadn't worked with SBCL before, so it took some reworking). It was well worth the trouble: the page loading speed is now so fast I can't really measure it - fractions of a second. Question: does anyone know a way to profile handlers? I tried the usual method using TIME, but its alot of trouble trying to capture its output, and anyway it returns all 0 times and a few thousand cons', which is clearly not right. Regards, --Jeff

4 3