November 2004 - tbnl-devel@common-lisp.net

[tbnl-devel] Handling HTTP errors
by Stefan Scholl 01 Mar '05

01 Mar '05

Hi! Function send-output in modlisp.lisp handles the response for different return codes. E. g. there's a "The requested URL ~A was not found on this server." for the 404 (+http-not-found+). How about letting the user change this behavior? One could explain the error to the user. Maybe in another language. Or think of all the funny 404 games. Remember the SGI babies? There could be different approaches: * Simple hash A hash with error code as key and handler as value. + Easy to implement + Can handle all errors (thrown by handlers _and_ when no dispatcher is found) - Not very flexible. Just checks for the code and not for any request data. * Error dispatcher Like the normal dispatcher, but checking for the right error output handler. + Can handle all errors (thrown by handlers _and_ when no dispatcher is found) + Flexible. Can check the code _and_ request data. - A bit big. The same effort like handling normal requests. * Handler outputs itself and signals that A handler wants to return a 404. It constructs the output string and signals the fact that there's no need for TBNL to build the HTML for the output. + Easy to implement(? clean?) + Flexible - Can't handle all errors. (No handler found? Then the code won't be executed.) Regards, Stefan

2 3

[tbnl-devel] Re: [mod-lisp-devel] Apache 2 support
by Edi Weitz 01 Dec '04

01 Dec '04

On Wed, 10 Nov 2004 19:36:35 +0100, "Marc Battyani" <marc.battyani(a)fractalconcept.com> wrote: > Don't bet ;-) I'm always horrified by the time it takes when I write > some C code like that. allocation/deallocation/pointers/tortuous > poorly documented APIs (I had to read the Apache sources to > understand what they mean with their threadkey stuff...) > etc. bleah... Same here... :( I'm going to spend some time with this now. If you've got something better to do (like fighting deadlines or playing with your kids) please do it and wait until I give up or deliver something. Maybe tonight. Cheers, Edi.

2 10

[tbnl-devel] backtraces in openMCL
by ocorrain＠yahoo.com 29 Nov '04

29 Nov '04

Hello Edi-- this piece implements backtraces in OpenMCL, though there may be a more beautiful way. Setting "detailed-p" to t results in a cranial overflow in my case :-) -- Tiarnán

2 1

Re: [tbnl-devel] TBNL on Darwin/MacOS X with SBCL/OpenMCL
by Tiarnan O'Corrain 11 Nov '04

11 Nov '04

Edi Weitz <edi(a)agharta.de> writes: > [I]t's probably due to KMRCL because > I'm pretty sure that the rest of TBNL doesn't contain > implementation-specific code. You're right, it was processes.lisp in KMRCL. I hacked in support for OpenMCL's native threads on Darwin and everything seems to work now. I also see that file uploads and multipart/form-data encoding work now as well. Wonderful! regards Tiarnan ===== Tiarnan O Corrain (on-site at Vodafone NL mobile: +353 86 831 0249 mail: ocorrain(a)yahoo.com)

2 1

[tbnl-devel] Re: [mod-lisp-devel] Apache 2 support
by Edi Weitz 10 Nov '04

10 Nov '04

On Wed, 10 Nov 2004 18:06:46 +0100, "Marc Battyani" <marc.battyani(a)fractalconcept.com> wrote: > I'm making it thread friendly now. > It should be available for testing this evening. Oh, it's good you're saying this - I was about to do the same thing... :) So I'll be doing something else, I'm sure you're faster. I was going to use the APR library, something like apr_threadkey_private_set/get. Is that your plan, too? Cheers, Edi.

1 0

[tbnl-devel] Re: [mod-lisp-devel] Apache 2 support
by Edi Weitz 10 Nov '04

10 Nov '04

On Wed, 10 Nov 2004 14:20:38 +0100, "Marc Battyani" <marc.battyani(a)fractalconcept.com> wrote: > I always wanted to test and finalize those versions but never found > the time to do it. The major points are the treading model and the > socket reuse. Have you also tested these points ? (The problem is > to have thread specific variables for the socket variables (no > special vars in C :( )) Yes, I tried to test these things, too. The code seems to keep the socket info in the configuration records. We know that this didn't work for 1.3.x[1] but it seems to work for 2.x. I inserted logging statements to check whether the sockets are actually re-used and they obviously /are/ re-used. I also tried to test whether there are issues with multiple mod_lisp instances[2] but I couldn't break the code. What I did was something like this: Start two different mod_lisp instances from different Lisp images in different locations. Then run ApacheBench to request a page from the first image several thousand times. Finally request a page from the second image manually one or more times. This was always enough to break mod_lisp prior to 2.37 but doesn't generate errors with mod_lisp2. Maybe my test methodology is flawed but at the moment I'm pretty sure that everything works fine. Perhaps Chris wants to comment on these issues. What I saw was that mod_lisp2 with Apache 2 seems to be a bit slower than mod_lisp with Apache 1.3 - something like 280 requests per second versus 340 requests per second (on VMWare). I'm not sure if this is due to Apache 2 or due to mod_lisp2, though. From a quick glance at the code it seems that mod_lisp2 does a lot of error checking which I think is a good thing. I don't mind if this results in a speed decrease that's barely noticable unless you've hundreds of simultaneously connected clients. Also, please note that I only ran these tests on Linux. On Windows (which supposedly has another default threading model) I only checked whether the standard TBNL tests succeeded. Cheers, Edi. [1] <http://common-lisp.net/pipermail/mod-lisp-devel/2004-July/000007.html> [2] <http://common-lisp.net/pipermail/mod-lisp-devel/2004-August/000018.html>

1 1

[tbnl-devel] Apache 2 support
by Edi Weitz 09 Nov '04

09 Nov '04

Hi! Several TBNL users have reported success with Chris Hanson's mod_lisp2[1] which seems to be a full reimplementation of Marc's mod_lisp for Apache 2, so I decided to try it out myself because a customer of mine wants to use Apache 2. I turned out that it was completely painless to use mod_lisp2 with Apache 2.0.52 on Linux as well as on Windows - the module worked out of the box and some tests seem to show that it doesn't suffer from the "leaked children" and "leaked sockets" problems we had with some versions of mod_lisp. I've added some lines of code to send headers that TBNL likes to have but other than that it's all Chris Hanson's code at <http://weitz.de/files/mod_lisp2.c> which I think I can recommend for TBNL. I hope some other people will try and test it as well. Marc - feel free to add this to your subversion repository if you want. I've also uploaded a pre-compiled module for the Win32 version of Apache 2 which worked for me with Apache 2.0.52, TBNL 0.3.1 (released some minutes ago), and either AllegroCL 6.2 trial or LispWorks 4.3.7 pro. It's here: <http://weitz.de/files/mod_lisp2.so> Cheers, Edi. [1] <http://www.fractalconcept.com:8000/public/open-source/mod_lisp/contrib/mod_…>

1 0

[tbnl-devel] New version 0.3.1
by Edi Weitz 09 Nov '04

09 Nov '04

Changelog entry: Version 0.3.1 2004-11-09 Slight changes to support Chris Hanson's mod_lisp2 Changed GET-BACKTRACE for newer SBCL versions (thanks to Nikodemus Siivola) Download from <http://weitz.de/files/tbnl.tar.gz> See <http://weitz.de/tbnl/#install> for Apache 2 support. Cheers, Edi.

1 0

[tbnl-devel] multipart/form-data forms, RFC2388, File Uploads
by Michael Weber 09 Nov '04

09 Nov '04

Hi, Attached is a patch with my stab at file upload capabilities for TBNL. :) [To my defense, I first played around with rfc2388. Then I switched to TBNL and found it to be rather straight-forward to add this functionality. Only afterwards I found out about the efforts of others regarding file uploads for TBNL.] Anyway, here's what the patch is about: * Adds support for multipart/form-data forms. * Can parse rfc2388 MIME data. * Enables file upload. * Introduces POST-PARAMETER* and POST-PARAMETERS* to give richer information about posted data (MIME headers). Also, the starred versions collate parameters with equal name into a list. + If successful, POST-PARAMETER* returns a list of MIME-PARTs, each of which can be further poked at with accessors exported from RFC2388. + POST-PARAMETERS* returns the corresponding hash-table. * Is backwards compatible with original TBNL, although the old interface is less efficiently implemented now (conses more). * Uses a slightly patched rfc2388.lisp (http://common-lisp.net/project/rfc2388) by Janis Dzerins, which is included completely in the patch. * Adds a file upload example to test/test.lisp (sessions.html). It is not very polished, though. Issues: * I tested with SBCL-0.8.15, and occasionally I get Apache "internal server errors" (caused by SIGPIPE errors on the Lisp side). It seems to be dependant on which file is uploaded. I did not look into it yet... * DOES NOT provide functionality to handle transfer encodings. The application is on its own there for now. Mind you, the whole thing is just a first try. Perhaps it needs a better/richer API, too, but this one is simple, and works for me, YMMV. Cheers, Michael p.s.: I noticed, there is at least one other CL rfc2388 implementation available, in mel-base.

2 2

[tbnl-devel] TBNL on Darwin/MacOS X with SBCL/OpenMCL
by ocorrain＠yahoo.com 08 Nov '04

08 Nov '04

Hello-- does TBNL work on MacOS X with either SBCL or OpenMCL? I'm using mod_lisp 2.38 and Apache 1.3.31. However, requests to the tbnl-test pages hang randomly, and sometimes I get the rather scary: [Mon Nov 8 18:48:53 2004] [error] [TBNL] illegal instruction at #X406C4FA8 -- Tiarnán

2 1