From michaelw+tbnl at foldr.org Sat Nov 3 08:45:14 2007 From: michaelw+tbnl at foldr.org (Michael Weber) Date: Sat, 3 Nov 2007 09:45:14 +0100 Subject: [hunchentoot-devel] Hunchentoot not working on OpenMCL 1.1pre In-Reply-To: References: Message-ID: <868B13B7-2FEB-4918-8C2F-48B47CDD0EA1@foldr.org> On Oct 20, 2007, at 02:05 , Edi Weitz wrote: > On Sun, 20 May 2007 12:32:53 +0100, "Tiarnan O'Corrain" > wrote: > >> Stream #> ISO-8859-1) #x93BC97E> is private to #> hunchentoot-worker-1(48) [Exhausted] #x93BBC1E> >> [Condition of type SIMPLE-ERROR] > > This should hopefully be fixed with release 0.14.4 - finally... > > Please try. Works for me, thanks! However, I still run into problems with :hunchentoot-no-ssl on *features* because openmcl does not like "#-foo #-foo" constructs. With openmcl-1.1pre, I get: (progn 0 #-openmcl 1 #-openmcl 2) ;; => 0 (OK) (progn 0 #-openmcl #-openmcl 1 2) ;; => 2 (WRONG) With the attached patch, everything works fine. (I did not test without :hunchentoot-no-ssl, because I cannot load cl +ssl into openmcl64, likely due to my (DarwinPorts) openssl being compiled for 32-bit. If somebody has done that already on OSX/Intel (Tiger), I'd love to hear about it.) Cheers, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot-reader-conditionals.patch Type: application/octet-stream Size: 2714 bytes Desc: not available URL: -------------- next part -------------- From edi at agharta.de Sat Nov 3 21:49:30 2007 From: edi at agharta.de (Edi Weitz) Date: Sat, 03 Nov 2007 22:49:30 +0100 Subject: [hunchentoot-devel] New release 0.14.5 Message-ID: ChangeLog: Version 0.14.5 2007-10-21 Robustified MAKE-SOCKET-STREAM against potential leak (thanks to Alain Picard) Replaced #-FOO #-FOO constructs for OpenMCL (patch by Michael Weber) Updated tutorial links Download: http://weitz.de/files/hunchentoot.tar.gz From ocorrain at gmail.com Wed Nov 7 21:56:28 2007 From: ocorrain at gmail.com (Tiarnan O'Corrain) Date: Wed, 7 Nov 2007 21:56:28 +0000 Subject: [hunchentoot-devel] New release 0.14.5 In-Reply-To: References: Message-ID: Hi-- this isn't working on Openmcl pre 1.1 ("Version 1.1-pre-070722 (DarwinPPC32)"). I get the following error on trying to access the test page with *catch-errors-p* set to nil. Special operator or global macro-function HUNCHENTOOT::IGNORE-ERRORS can't be FUNCALLed or APPLYed [Condition of type CCL::CALL-SPECIAL-OPERATOR-OR-MACRO] Without it the server never returns. I've updated to the latest versions of chunga and flexi-streams. regards Tiarn?n From ctdean at sokitomi.com Wed Nov 7 22:11:19 2007 From: ctdean at sokitomi.com (Chris Dean) Date: Wed, 07 Nov 2007 14:11:19 -0800 Subject: [hunchentoot-devel] New release 0.14.5 In-Reply-To: (Tiarnan O'Corrain's message of "Wed, 7 Nov 2007 21:56:28 +0000") References: Message-ID: > Special operator or global macro-function HUNCHENTOOT::IGNORE-ERRORS > can't be FUNCALLed or APPLYed > [Condition of type CCL::CALL-SPECIAL-OPERATOR-OR-MACRO] I believe the asdf build order may be incorrect to get hunchentoot::ignore-errors defined before use. A quick work around is to recompile all the .lisp files after making sure the hunchentoot is loaded. Cheers, Chris Dean From ocorrain at gmail.com Wed Nov 7 22:11:57 2007 From: ocorrain at gmail.com (Tiarnan O'Corrain) Date: Wed, 7 Nov 2007 22:11:57 +0000 Subject: [hunchentoot-devel] New release 0.14.5 In-Reply-To: References: Message-ID: Hi-- some more details -- it seems that make-socket-stream in port-mcl is getting called without a 'handle' argument, tho' everything looks ok in server.lisp -- here's the relevant bit of the backtrace: 16: (HUNCHENTOOT::MAKE-SOCKET-STREAM 20 20 '(# #)) Locals: HUNCHENTOOT::READ-TIMEOUT = 20 HUNCHENTOOT::WRITE-TIMEOUT = 20 17: (HUNCHENTOOT::PROCESS-CONNECTION # #) Locals: HUNCHENTOOT::SERVER = # HUNCHENTOOT::HANDLE = # #:COMPILER-VAR = (NIL) #:G4816 = (ERROR # WARNING #) CCL::%HANDLERS% = ((PROCESS-RESET)) #:G4817 = (ERROR #) CCL::%HANDLERS% = ((ERROR # WARNING #) (PROCESS-RESET)) HUNCHENTOOT::*HUNCHENTOOT-STREAM* = # HUNCHENTOOT::*LOCAL-HOST* = # HUNCHENTOOT::*REMOTE-HOST* = # HUNCHENTOOT::*REMOTE-PORT* = # CCL::*INTERRUPT-LEVEL* = 0 CCL::*INTERRUPT-LEVEL* = -1 HUNCHENTOOT:*SERVER* = # Catch-tags: NIL NIL From ocorrain at gmail.com Wed Nov 7 22:16:51 2007 From: ocorrain at gmail.com (Tiarnan O'Corrain) Date: Wed, 7 Nov 2007 22:16:51 +0000 Subject: [hunchentoot-devel] New release 0.14.5 In-Reply-To: References: Message-ID: Hmm, that gets me the default page, but the test page is still hanging. On Nov 7, 2007 10:11 PM, Chris Dean wrote: > > > Special operator or global macro-function HUNCHENTOOT::IGNORE-ERRORS > > can't be FUNCALLed or APPLYed > > [Condition of type CCL::CALL-SPECIAL-OPERATOR-OR-MACRO] > > I believe the asdf build order may be incorrect to get > hunchentoot::ignore-errors defined before use. A quick work around is > to recompile all the .lisp files after making sure the hunchentoot is > loaded. > > Cheers, > Chris Dean > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- These plunderers of the world, after exhausting the land by their devastations, are rifling the ocean: stimulated by avarice, if their enemy be rich; by ambition, if poor; unsatiated by the East and by the West: the only people who behold wealth and indigence with equal avidity. To ravage, to slaughter, to usurp under false titles, they call empire; and where they make a desert, they call it peace. From ctdean at sokitomi.com Wed Nov 7 22:28:12 2007 From: ctdean at sokitomi.com (Chris Dean) Date: Wed, 07 Nov 2007 14:28:12 -0800 Subject: [hunchentoot-devel] New release 0.14.5 In-Reply-To: (Tiarnan O'Corrain's message of "Wed, 7 Nov 2007 22:16:51 +0000") References: Message-ID: "Tiarnan O'Corrain" writes: > Hmm, that gets me the default page, but the test page is still hanging. Are you using: (asdf:oos 'asdf:load-op :hunchentoot-test) (hunchentoot:start-server :port 4242) and visiting http://localhost:4242/hunchentoot/test to get a test page? FWIW, that works fine for me on LispWorks on OS X. Cheers, Chris Dean From ocorrain at gmail.com Wed Nov 7 22:39:56 2007 From: ocorrain at gmail.com (Tiarnan O'Corrain) Date: Wed, 7 Nov 2007 22:39:56 +0000 Subject: [hunchentoot-devel] New release 0.14.5 In-Reply-To: References: Message-ID: Ah, I starting everything afresh (after individually compiling the lisp files as you suggested), and it works now. CL-USER> (format t "~A ~A ~A ~A" (machine-type) (machine-version) (lisp-implementation-type) (lisp-implementation-version)) Power Macintosh PowerBook5,4 OpenMCL Version 1.1-pre-070722 (DarwinPPC32) Thanks for your help. Hopefully I'll get a chance to investigate why it doesn't work 'out of the box' at some point. T From edi at agharta.de Thu Nov 8 15:02:41 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 08 Nov 2007 16:02:41 +0100 Subject: [hunchentoot-devel] Re: Chained SSL certificates with hunchentoot/cl+ssl In-Reply-To: (Juhani =?iso-8859-1?q?R=E4nkimies's?= message of "Mon, 5 Nov 2007 11:30:53 +0200") References: Message-ID: [Cc to tbnl-devel which seems to work again. Please continue the discussion there.] On Mon, 5 Nov 2007 11:30:53 +0200, "Juhani R?nkimies" wrote: > I'm sorry for mailing you directly. I tried to join > cl-plus-ssl-devel and tbln-devel mailing lists, but for some reason > the confirmation emails never reached my mailbox. There was a problem with Mailman on common-lisp.net which seems to be fixed now. > I wanted to use a chained certificate without Apache or anything > else in front of hunchentoot and came up with a hack that enabled > it. > > My notes on the hack can be found at > https://www.juranki.net/ht/hunchentoot-chained-certificate.html (if > you're using IE, you're going to get a security alert because the CA > I'm experimenting with is not trusted by IE) > > I would like this capability to be added to hunchentoot/cl+ssl, but > before doing more work I'd like to hear your comments. > > Do you see the solution as a valid one? > If so, how to proceed? > If not, what's the better way to do it? I only looked at it briefly, but at first glance it seems to be OK. However, for something to be accepted as a patch to Hunchentoot see the notes here: http://weitz.de/patches.html Thanks, Edi. From juhani at juranki.com Thu Nov 8 16:49:24 2007 From: juhani at juranki.com (=?ISO-8859-1?Q?Juhani_R=E4nkimies?=) Date: Thu, 8 Nov 2007 18:49:24 +0200 Subject: [hunchentoot-devel] Re: Chained SSL certificates with hunchentoot/cl+ssl In-Reply-To: References: Message-ID: > > There was a problem with Mailman on common-lisp.net which seems to be > fixed now. Yes, I'm a member now. Thanks. > > > I wanted to use a chained certificate without Apache or anything > > else in front of hunchentoot and came up with a hack that enabled > > it. > > > > My notes on the hack can be found at > > https://www.juranki.net/ht/hunchentoot-chained-certificate.html (if > > you're using IE, you're going to get a security alert because the CA > > I'm experimenting with is not trusted by IE) > > > > I would like this capability to be added to hunchentoot/cl+ssl, but > > before doing more work I'd like to hear your comments. > > > > Do you see the solution as a valid one? > > If so, how to proceed? > > If not, what's the better way to do it? > > I only looked at it briefly, but at first glance it seems to be OK. > However, for something to be accepted as a patch to Hunchentoot see > the notes here: > > http://weitz.de/patches.html I further examined the behaviour of the openssl functions and found that its possible to solve the problem without modifying hunchentoot, by first loading a ca-bundle, containing ca and intermediate certificates, to global context and then using the existing hunchentoot api to specify the private key and server certificate. A patch to cl+ssl and some notes can be found at https://www.juranki.net/ht/hunchentoot-chained-certificate-v3.html br, -juhani From edi at agharta.de Thu Nov 8 17:30:34 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 08 Nov 2007 18:30:34 +0100 Subject: [hunchentoot-devel] Re: Chained SSL certificates with hunchentoot/cl+ssl In-Reply-To: (Juhani =?iso-8859-1?q?R=E4nkimies's?= message of "Thu, 8 Nov 2007 18:49:24 +0200") References: Message-ID: On Thu, 8 Nov 2007 18:49:24 +0200, "Juhani R?nkimies" wrote: > I further examined the behaviour of the openssl functions and found > that its possible to solve the problem without modifying > hunchentoot, by first loading a ca-bundle, containing ca and > intermediate certificates, to global context and then using the > existing hunchentoot api to specify the private key and server > certificate. OK, that's even better... :) Thanks, Edi. From edi at agharta.de Thu Nov 8 20:10:47 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 08 Nov 2007 21:10:47 +0100 Subject: [hunchentoot-devel] New release 0.14.6 In-Reply-To: (Chris Dean's message of "Wed, 07 Nov 2007 14:11:19 -0800") References: Message-ID: On Wed, 07 Nov 2007 14:11:19 -0800, Chris Dean wrote: >> Special operator or global macro-function HUNCHENTOOT::IGNORE-ERRORS >> can't be FUNCALLed or APPLYed >> [Condition of type CCL::CALL-SPECIAL-OPERATOR-OR-MACRO] > > I believe the asdf build order may be incorrect to get > hunchentoot::ignore-errors defined before use. You're right - macros should of course be defined before they're used. D'oh! Should be fixed now. Thanks, Edi. From ocorrain at gmail.com Thu Nov 8 20:16:38 2007 From: ocorrain at gmail.com (Tiarnan O'Corrain) Date: Thu, 8 Nov 2007 20:16:38 +0000 Subject: [hunchentoot-devel] New release 0.14.6 In-Reply-To: References: Message-ID: Hi Edi-- superb -- it works out of the box now. thanks, Tiarn?n From jcm at sdf.lonestar.org Sun Nov 11 17:58:59 2007 From: jcm at sdf.lonestar.org (Jonathon McKitrick) Date: Sun, 11 Nov 2007 17:58:59 +0000 Subject: [hunchentoot-devel] Hunchentoot and/or CLOS? Message-ID: <20071111175859.GB5792@SDF.LONESTAR.ORG> I've been reading up on ucw and lisp-on-lines, and I thought I'd ask you all a couple of questions: Have you found OO development with CLOS, such as offered by ucw and lisp-on-lines to be flexible and useful for web application development, or have you found functional approaches to be better? And given that hunchentoot seems to be the most robust and well-supported of the pure lisp servers (AFAIK) would it be useful to port some or all of ucw and/or lol functionality to work with hunchentoot? Jonathon McKitrick -- My other computer is your Windows box. From xach at xach.com Sun Nov 11 21:35:14 2007 From: xach at xach.com (Zach Beane) Date: Sun, 11 Nov 2007 16:35:14 -0500 Subject: [hunchentoot-devel] Hunchentoot and/or CLOS? In-Reply-To: <20071111175859.GB5792@SDF.LONESTAR.ORG> References: <20071111175859.GB5792@SDF.LONESTAR.ORG> Message-ID: <20071111213514.GX1985@xach.com> On Sun, Nov 11, 2007 at 05:58:59PM +0000, Jonathon McKitrick wrote: > I've been reading up on ucw and lisp-on-lines, and I thought I'd ask you all > a couple of questions: > > Have you found OO development with CLOS, such as offered by ucw and > lisp-on-lines to be flexible and useful for web application development, or > have you found functional approaches to be better? And given that > hunchentoot seems to be the most robust and well-supported of the pure lisp > servers (AFAIK) would it be useful to port some or all of ucw and/or lol > functionality to work with hunchentoot? UCW and Lisp-on-Lines offer a system for developing web applications that use continuations to hide the stateless nature of HTTP requests. I haven't used either one, or the continuation technique, but I tend to think of them as a layer atop a system like Hunchentoot that provides access to explicit requests & responses. OO and CLOS are are orthogonal to continuations. I use OO and CLOS for my Hunchentoot applications all the time, but I don't use continuations. I think UCW can run on top of Hunchentoot already. No porting needed. Zach From jcm at sdf.lonestar.org Tue Nov 13 13:46:28 2007 From: jcm at sdf.lonestar.org (Jonathon McKitrick) Date: Tue, 13 Nov 2007 13:46:28 +0000 Subject: [hunchentoot-devel] Hunchentoot and/or CLOS? In-Reply-To: <20071111213514.GX1985@xach.com> References: <20071111175859.GB5792@SDF.LONESTAR.ORG> <20071111213514.GX1985@xach.com> Message-ID: <20071113134628.GA25109@SDF.LONESTAR.ORG> On Sun, Nov 11, 2007 at 04:35:14PM -0500, Zach Beane wrote: : On Sun, Nov 11, 2007 at 05:58:59PM +0000, Jonathon McKitrick wrote: : > I've been reading up on ucw and lisp-on-lines, and I thought I'd ask you all : > a couple of questions: : > : > Have you found OO development with CLOS, such as offered by ucw and : > lisp-on-lines to be flexible and useful for web application development, or : > have you found functional approaches to be better? And given that : > hunchentoot seems to be the most robust and well-supported of the pure lisp : > servers (AFAIK) would it be useful to port some or all of ucw and/or lol : > functionality to work with hunchentoot? : : UCW and Lisp-on-Lines offer a system for developing web applications : that use continuations to hide the stateless nature of HTTP : requests. I haven't used either one, or the continuation technique, : but I tend to think of them as a layer atop a system like Hunchentoot : that provides access to explicit requests & responses. : : OO and CLOS are are orthogonal to continuations. I use OO and CLOS for : my Hunchentoot applications all the time, but I don't use : continuations. Thanks for the helpful response. Just a quick follow-up: where have you found OO and CLOS most useful - representing entire pages, components on a page, or even items within components? Jonathon McKitrick -- My other computer is your Windows box. From xach at xach.com Tue Nov 13 14:17:05 2007 From: xach at xach.com (Zach Beane) Date: Tue, 13 Nov 2007 09:17:05 -0500 Subject: [hunchentoot-devel] Hunchentoot and/or CLOS? In-Reply-To: <20071113134628.GA25109@SDF.LONESTAR.ORG> References: <20071111175859.GB5792@SDF.LONESTAR.ORG> <20071111213514.GX1985@xach.com> <20071113134628.GA25109@SDF.LONESTAR.ORG> Message-ID: <20071113141705.GF1985@xach.com> On Tue, Nov 13, 2007 at 01:46:28PM +0000, Jonathon McKitrick wrote: > Thanks for the helpful response. Just a quick follow-up: where have you > found OO and CLOS most useful - representing entire pages, components on a > page, or even items within components? I just use them willy-nilly. Wherever something seems like it should be a GF or object, I make it so. I couldn't tell you where it seems the *most* useful. Zach From hans at huebner.org Wed Nov 14 16:08:54 2007 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 14 Nov 2007 17:08:54 +0100 Subject: [hunchentoot-devel] Workaround for OpenMCL bug in ENOUGH-NAMESTRING Message-ID: Hi, OpenMCL has a bug in ENOUGH-NAMESTRING that makes Hunchentoot fail when the "/" prefix is exported from the file system using CREATE-FOLDER-DISPATCHER-AND-HANDLER. ENOUGH-NAMESTRING fails to work for URI paths having more than one component. As URI strings are not path names, I find using ENOUGH-NAMESTRING being a little fishy here anyway and I'd propose the following patch, courtesy of Kilian Sprotte: Index: misc.lisp =================================================================== --- misc.lisp (revision 2274) +++ misc.lisp (working copy) @@ -177,6 +177,11 @@ (lambda () (handle-static-file path content-type))))) +(defun enough-url (url url-prefix) + "Return the relative portion of URL relative to URL-PREFIX, similar +to what enough-pathname does for path names." + (subseq url (mismatch url url-prefix))) + (defun create-folder-dispatcher-and-handler (uri-prefix base-path &optional con tent-type) "Creates and returns a dispatch function which will dispatch to a handler function which emits the file relative to BASE-PATH that is @@ -193,8 +198,8 @@ (error "~S is supposed to denote a directory." base-path)) (flet ((handler () (let* ((script-name (url-decode (script-name))) - (script-path (enough-namestring (regex-replace-all "\\\\" scr ipt-name "/") - uri-prefix)) + (script-path (enough-url (regex-replace-all "\\\\" script-nam e "/") + uri-prefix)) (script-path-directory (pathname-directory script-path))) (unless (or (stringp script-path-directory) (null script-path-directory) From tritchey at mac.com Wed Nov 14 16:46:22 2007 From: tritchey at mac.com (Timothy Ritchey) Date: Wed, 14 Nov 2007 11:46:22 -0500 Subject: [hunchentoot-devel] Workaround for OpenMCL bug in ENOUGH-NAMESTRING In-Reply-To: References: Message-ID: <88050A9B-1350-4189-950F-573E7616134B@mac.com> This bug also exists in older versions of SBCL in case anyone has run into it. 0.9.12 is known to not work, but later versions (1.0.10 for example) do. Cheers, Tim On Nov 14, 2007, at 11:08 AM, Hans H?bner wrote: > Hi, > > OpenMCL has a bug in ENOUGH-NAMESTRING that makes Hunchentoot fail > when the "/" prefix is exported from the file system using > CREATE-FOLDER-DISPATCHER-AND-HANDLER. ENOUGH-NAMESTRING fails to work > for URI paths having more than one component. As URI strings are not > path names, I find using ENOUGH-NAMESTRING being a little fishy here > anyway and I'd propose the following patch, courtesy of Kilian > Sprotte: > > Index: misc.lisp > =================================================================== > --- misc.lisp (revision 2274) > +++ misc.lisp (working copy) > @@ -177,6 +177,11 @@ > (lambda () > (handle-static-file path content-type))))) > > +(defun enough-url (url url-prefix) > + "Return the relative portion of URL relative to URL-PREFIX, similar > +to what enough-pathname does for path names." > + (subseq url (mismatch url url-prefix))) > + > (defun create-folder-dispatcher-and-handler (uri-prefix base-path > &optional con > tent-type) > "Creates and returns a dispatch function which will dispatch to a > handler function which emits the file relative to BASE-PATH that is > @@ -193,8 +198,8 @@ > (error "~S is supposed to denote a directory." base-path)) > (flet ((handler () > (let* ((script-name (url-decode (script-name))) > - (script-path (enough-namestring (regex-replace- > all "\\\\" scr > ipt-name "/") > - uri-prefix)) > + (script-path (enough-url (regex-replace-all "\\\ > \" script-nam > e "/") > + uri-prefix)) > (script-path-directory (pathname-directory script- > path))) > (unless (or (stringp script-path-directory) > (null script-path-directory) > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From edi at agharta.de Thu Nov 15 07:36:43 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 15 Nov 2007 08:36:43 +0100 Subject: [hunchentoot-devel] New release 0.14.7 (Was: Workaround for OpenMCL bug in ENOUGH-NAMESTRING) In-Reply-To: (Hans =?iso-8859-1?q?H=FCbner's?= message of "Wed, 14 Nov 2007 17:08:54 +0100") References: Message-ID: Hi Hans, On Wed, 14 Nov 2007 17:08:54 +0100, "Hans H?bner" wrote: > OpenMCL has a bug in ENOUGH-NAMESTRING that makes Hunchentoot fail > when the "/" prefix is exported from the file system using > CREATE-FOLDER-DISPATCHER-AND-HANDLER. ENOUGH-NAMESTRING fails to > work for URI paths having more than one component. As URI strings > are not path names, I find using ENOUGH-NAMESTRING being a little > fishy here anyway and I'd propose the following patch, courtesy of > Kilian Sprotte: Thanks. I've released a new version which incorporates your patch. Untested, as I'm currently in the process of re-installing my OS and my Lisps on my laptop. The next time please send the patch as a an attachment or use a mail client which doesn't break lines willy-nilly... :) Cheers, Edi. From hans at huebner.org Thu Nov 15 07:38:54 2007 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 15 Nov 2007 08:38:54 +0100 Subject: [hunchentoot-devel] New release 0.14.7 (Was: Workaround for OpenMCL bug in ENOUGH-NAMESTRING) In-Reply-To: References: Message-ID: On Nov 15, 2007 8:36 AM, Edi Weitz wrote: > Thanks. I've released a new version which incorporates your patch. > Untested, as I'm currently in the process of re-installing my OS and > my Lisps on my laptop. Thanks! I talk all the blame should this fail for anyone. > The next time please send the patch as a an attachment or use a mail > client which doesn't break lines willy-nilly... :) Will do. I was unsure whether the list accepts attachments, but as it is for patches, it?d propably be stupid to be unsure about that. -Hans From edi at agharta.de Thu Nov 15 07:46:13 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 15 Nov 2007 08:46:13 +0100 Subject: [hunchentoot-devel] New release 0.14.7 In-Reply-To: (Hans =?iso-8859-1?q?H=FCbner's?= message of "Thu, 15 Nov 2007 08:38:54 +0100") References: Message-ID: On Thu, 15 Nov 2007 08:38:54 +0100, "Hans H?bner" wrote: > I was unsure whether the list accepts attachments, but as it is for > patches, it?d propably be stupid to be unsure about that. It lets attachments go through up to a certain size and for larger attachments I (as the list admin) can decide on a case-by-case basis. From edi at agharta.de Thu Nov 22 09:30:38 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 22 Nov 2007 10:30:38 +0100 Subject: [hunchentoot-devel] Re: Hunchentoot's query parameter seperator In-Reply-To: (Kyle R. Burton's message of "Tue, 20 Nov 2007 09:31:01 -0500") References: Message-ID: Hi, On Tue, 20 Nov 2007 09:31:01 -0500, "Kyle R. Burton" wrote: > I'm not sure if there is a mailing list that would be more > appropriate. Really? http://weitz.de/hunchentoot/#mail I'd appreciate if we could continue this discussion on the list, see Cc. (You have to subscribe first, of course.) > I'd like to start by saying thanks for Hunchentoot! (and all the > other CL libraries you've developed). You're welcome... :) > I am just starting with Hunchentoot, but I noticed that the query > string parser supports ampersand (&) as a pair separator and I > rememberd semi-colon (;) also being a valid separator for query > strings. I only remember this from having worked with Perl's CGI. > A bit of quick searching on the net lead me to: > > http://en.wikipedia.org/wiki/Query_string > http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2 > > to confirm that the semi-colon is mentioned as a separator. I have to admit that this is the first time I've heard of this recommendation. A quick test with the vastly popular PHP shows that they don't implement it either: Try these: http://zappa.agharta.de/test.html?foo=bar&baz=quux http://zappa.agharta.de/test.html?foo=bar;baz=quux So, to everyone on the list - what's your experience with semicolons as query string separators? Is this normal or esoteric? And, even more interesting, does any client out there actually use this convention? > I looked into the sources and I think the minor change is in > defmethod initialize-instance :after, to just update the split from: > > (form-url-encoded-list-to-alist (split "&" query-string)) > > to > > (form-url-encoded-list-to-alist (split "[;&]" query-string)) > > A quick empirical test with a browser shows symptoms of working: > > /lisp/test?foo=bar&qux=baz&blarf=qbozzle > /lisp/test?foo=bar;qux=baz;blarf=qbozzle > > I'm new to CL so I'm not entirely confident of my suggestion... Seems OK, but it might break existing applications. > Also, is there a place in the source tree for any kind of unit tests > or assertions? I'd have added one for this test, but I didn't > recognize where it would have been appropriate to put it. No, only the demo in the "test/" directory. > Is this something you'd consider enhancing Hunchentoot with? Lots of stuff... Cheers, Edi. From rsynnott at gmail.com Thu Nov 22 13:50:25 2007 From: rsynnott at gmail.com (Robert Synnott) Date: Thu, 22 Nov 2007 13:50:25 +0000 Subject: [hunchentoot-devel] Re: Hunchentoot's query parameter seperator In-Reply-To: References: Message-ID: <24f203480711220550m42696a11g3248a3e0876d64e5@mail.gmail.com> On Nov 22, 2007 9:30 AM, Edi Weitz wrote: > Hi, > > On Tue, 20 Nov 2007 09:31:01 -0500, "Kyle R. Burton" wrote: > > > I'm not sure if there is a mailing list that would be more > > appropriate. > > Really? > > http://weitz.de/hunchentoot/#mail > > I'd appreciate if we could continue this discussion on the list, see > Cc. (You have to subscribe first, of course.) > > > I'd like to start by saying thanks for Hunchentoot! (and all the > > other CL libraries you've developed). > > You're welcome... :) > > > I am just starting with Hunchentoot, but I noticed that the query > > string parser supports ampersand (&) as a pair separator and I > > rememberd semi-colon (;) also being a valid separator for query > > strings. I only remember this from having worked with Perl's CGI. > > A bit of quick searching on the net lead me to: > > > > http://en.wikipedia.org/wiki/Query_string > > http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2 > > > > to confirm that the semi-colon is mentioned as a separator. > > I have to admit that this is the first time I've heard of this > recommendation. A quick test with the vastly popular PHP shows that > they don't implement it either: > > > > Try these: > > http://zappa.agharta.de/test.html?foo=bar&baz=quux > http://zappa.agharta.de/test.html?foo=bar;baz=quux > > So, to everyone on the list - what's your experience with semicolons > as query string separators? Is this normal or esoteric? And, even > more interesting, does any client out there actually use this > convention? > Esoteric these days; you still occasionally see it on the websites of newspapers using a certain CMS. I suspect it exists because of HTML's special treatment of the ampersand character; modern browsers are good at understanding ampersands used in HTTP requests, but I can imagine they were problematic in the past. I can't imagine any client does; not all that much server software supports it. It might be worth supporting it from a compliance point of view, but there may be a potential for breaking things; I don't think most clients will bother encoding semicolons, so things which previously worked might break. (Say, http://localhost/?phrase=this+is+a+test;+it+contains+a+semicolon ) Rob. -- Robert Synnott http://myblog.rsynnott.com MSN: rsynnott at gmail.com Jabber: rsynnott at gmail.com From edi at agharta.de Thu Nov 22 13:55:59 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 22 Nov 2007 14:55:59 +0100 Subject: [hunchentoot-devel] Re: Hunchentoot's query parameter seperator In-Reply-To: <24f203480711220550m42696a11g3248a3e0876d64e5@mail.gmail.com> (Robert Synnott's message of "Thu, 22 Nov 2007 13:50:25 +0000") References: <24f203480711220550m42696a11g3248a3e0876d64e5@mail.gmail.com> Message-ID: On Thu, 22 Nov 2007 13:50:25 +0000, "Robert Synnott" wrote: > but there may be a potential for breaking things; I don't think most > clients will bother encoding semicolons, so things which previously > worked might break. (Say, > http://localhost/?phrase=this+is+a+test;+it+contains+a+semicolon ) Right, that's what I was fearing as well. If someone needs this desperately enough to send a patch, then it should be made configurable and the default should be that the semicolon as a separator is disabled. Thanks, Edi. From eadmund42 at gmail.com Sat Nov 24 15:43:15 2007 From: eadmund42 at gmail.com (Robert Uhl) Date: Sat, 24 Nov 2007 08:43:15 -0700 Subject: [hunchentoot-devel] Re: Hunchentoot's query parameter seperator References: Message-ID: Edi Weitz writes: > > So, to everyone on the list - what's your experience with semicolons > as query string separators? I've used them a lot; they're my preferred method of separating query args. > Is this normal or esoteric? Something less than normal and more than esoteric, methinks. > And, even more interesting, does any client out there actually use > this convention? The clients don't create URL args; those are generated by the site in question or by the user's typing. For the same reason, I'm not certain that compatibility is a worry: if the client is requesting a URL the server previously served, surely that URL is A-OK. -- Robert Uhl You know there's going to be trouble when a laser capable of turning all intervening matter between source and target to vacuum is merely the warning shot. --SteveD From rm at seid-online.de Sat Nov 24 17:26:35 2007 From: rm at seid-online.de (Ralf Mattes) Date: Sat, 24 Nov 2007 18:26:35 +0100 Subject: [hunchentoot-devel] Re: Hunchentoot's query parameter seperator In-Reply-To: References: Message-ID: <1195925195.6575.12.camel@localhost.localdomain> On Sat, 2007-11-24 at 08:43 -0700, Robert Uhl wrote: > Edi Weitz writes: > > > > So, to everyone on the list - what's your experience with semicolons > > as query string separators? > > I've used them a lot; they're my preferred method of separating query > args. I personally never ever saw them used. > > Is this normal or esoteric? > > Something less than normal and more than esoteric, methinks. I disagree - the RFC (http://www.w3.org/TR/html4/interact/forms.html#form-content-type) is actually rather clear about this. Section 17.13.4 "Form content types" reads as follows: * application/x-www-form-urlencoded This is the default content type. Forms submitted with this content type must be encoded as follows: 1. Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A'). 2. The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'. And that's it. Nowhere does it even mention the use of #\; as a separator of name/value pairs. > > And, even more interesting, does any client out there actually use > > this convention? > > The clients don't create URL args; those are generated by the site in > question or by the user's typing. ??? I think you must missunderstand something here - of course the client application needs to construct an URL every time a user fills out a html form that uses the GET method. Please refer to section 17.13.3 "Processing form data" of the RFC. > For the same reason, I'm not certain that compatibility is a worry: if > the client is requesting a URL the server previously served, surely that > URL is A-OK. GET urls are usually _not_ served by the server but generated by the client application. How should a server process the following request: GET /foo/bar?name1=value1;&name2=value2 Do we expect 'name1' -> 'value1;' and 'name2' -> 'value2' or do we expect 'name1' -> 'value1' and ';name2' -> 'value2'???? Cheers, Ralf Mattes From lispercat at gmail.com Sat Nov 24 22:14:07 2007 From: lispercat at gmail.com (Andrei Stebakov) Date: Sat, 24 Nov 2007 17:14:07 -0500 Subject: [hunchentoot-devel] printing to *standard-output* in a multithreaded environment Message-ID: I wonder is it save to have a macro like this: (defmacro with-html (&body body) `(with-html-output-to-string (*standard-output* nil :prologue t) , at body)) with SBCL which is multithreaded. What happens when multiple users connect to the server and the requests are served using the macro above. I mean how do multiple threads share the *standard-output* in this case? Or should I create a new stream per request? Thank you, Andrew From xach at xach.com Sat Nov 24 22:22:23 2007 From: xach at xach.com (Zach Beane) Date: Sat, 24 Nov 2007 17:22:23 -0500 Subject: [hunchentoot-devel] printing to *standard-output* in a multithreaded environment In-Reply-To: References: Message-ID: <20071124222223.GJ3515@xach.com> On Sat, Nov 24, 2007 at 05:14:07PM -0500, Andrei Stebakov wrote: > I wonder is it save to have a macro like this: > (defmacro with-html (&body body) > `(with-html-output-to-string (*standard-output* nil :prologue t) > , at body)) > > > with SBCL which is multithreaded. > What happens when multiple users connect to the server and the > requests are served using the macro above. I mean how do multiple > threads share the *standard-output* in this case? Or should I create a > new stream per request? Dynamic bindings of special variables are per-thread, so they will not interfere with each other. Zach From lispercat at gmail.com Sat Nov 24 22:26:33 2007 From: lispercat at gmail.com (Andrei Stebakov) Date: Sat, 24 Nov 2007 17:26:33 -0500 Subject: [hunchentoot-devel] printing to *standard-output* in a multithreaded environment In-Reply-To: <20071124222223.GJ3515@xach.com> References: <20071124222223.GJ3515@xach.com> Message-ID: Thanks! Andrew On Nov 24, 2007 5:22 PM, Zach Beane wrote: > > On Sat, Nov 24, 2007 at 05:14:07PM -0500, Andrei Stebakov wrote: > > I wonder is it save to have a macro like this: > > (defmacro with-html (&body body) > > `(with-html-output-to-string (*standard-output* nil :prologue t) > > , at body)) > > > > > > with SBCL which is multithreaded. > > What happens when multiple users connect to the server and the > > requests are served using the macro above. I mean how do multiple > > threads share the *standard-output* in this case? Or should I create a > > new stream per request? > > Dynamic bindings of special variables are per-thread, so they will not > interfere with each other. > > Zach > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From eadmund42 at gmail.com Tue Nov 27 04:59:23 2007 From: eadmund42 at gmail.com (Robert Uhl) Date: Mon, 26 Nov 2007 21:59:23 -0700 Subject: [hunchentoot-devel] Re: Hunchentoot's query parameter seperator References: <1195925195.6575.12.camel@localhost.localdomain> Message-ID: Ralf Mattes writes: > >> > Is this normal or esoteric? >> >> Something less than normal and more than esoteric, methinks. > > I disagree - the RFC > (http://www.w3.org/TR/html4/interact/forms.html#form-content-type) is > actually rather clear about this. Section 17.13.4 "Form content types" > reads as follows: > > * application/x-www-form-urlencoded > This is the default content type. Forms submitted with this content > type must be encoded as follows: > > 1. Control names and values are escaped. Space characters are > replaced by `+', and then reserved characters are escaped as > described in [RFC1738], section 2.2: Non-alphanumeric characters > are replaced by `%HH', a percent sign and two hexadecimal digits > representing the ASCII code of the character. Line breaks are > represented as "CR LF" pairs (i.e., `%0D%0A'). > 2. The control names/values are listed in the order they appear in > the document. The name is separated from the value by `=' and > name/value pairs are separated from each other by `&'. > > And that's it. Nowhere does it even mention the use of #\; as a > separator of name/value pairs. That's for forms. Not all URLs are created from forms; in fact, the vast majority of URLs are _not_ thus created. Most are simply href anchors. >> > And, even more interesting, does any client out there actually use >> > this convention? >> >> The clients don't create URL args; those are generated by the site in >> question or by the user's typing. > > ??? I think you must missunderstand something here - of course the > client application needs to construct an URL every time a user fills out > a html form that uses the GET method. Please refer to section > 17.13.3 "Processing form data" of the RFC. I'd forgotten about forms. I was thinking about the normal case for GET urls. >> For the same reason, I'm not certain that compatibility is a worry: if >> the client is requesting a URL the server previously served, surely that >> URL is A-OK. > > GET urls are usually _not_ served by the server but generated by the > client application. *boggle* Every single time you click a link, that's a GET request. The vast, vast, _vast_ majority of GET requests are not generated by forms but by following links. > How should a server process the following request: > > GET /foo/bar?name1=value1;&name2=value2 > > Do we expect 'name1' -> 'value1;' and 'name2' -> 'value2' or > do we expect 'name1' -> 'value1' and ';name2' -> 'value2'???? RFC 2396 states that semicolons are reserved, and that if they conflict with a reserved purpose then they must be escaped; further, it states that 'Within a query component, the characters ";", "/", "?", ":", "@", "&", "=", "+", ",", and "$" are reserved.' Thus those semicolons would have meaning within a query. AFAIK, it's up to the server how to parse those characters, and thus Hunchentoot could be compliant and not parse them as most folks have come to expect. Me, I would parse your example as 'name1' -> 'value1'; an empty pair; 'name2' -> 'value2'. That is, I see semicolon and ampersand as equivalent to one another. Tim Berners-Lee in suggests a syntax for matrix URLs which uses semicolons. With a '?' prefixed it can be adapted to use the query syntax. Also, semicolons do not need to be HTML-escaped; ampersands must be. Thus it's convenient for HTML-writers to avoid ampersands; otherwise URLs must be written as /foo/bar?name1=value1&name2=value2 which gets very old very quickly. -- Robert Uhl >> Could someone tell me what are the advantages of kernel threads. >> Do they have faster context switches? > User level threads are faster. I believe that WinNT has now taken > user level threads, and called them `fibres,' so they now have > `processes,' `threads,' and `fibres.' I expect an announcement of > `single-chain polymers' to come next (the silliest thing is, I think > I know how to do them). --comp.os.linux.development.system From ocorrain at gmail.com Wed Nov 28 12:35:40 2007 From: ocorrain at gmail.com (Tiarnan O'Corrain) Date: Wed, 28 Nov 2007 12:35:40 +0000 Subject: [hunchentoot-devel] Hunchentoot on abcl? Message-ID: Hi-- I'm trying to get hunchentoot running on abcl, but it is balking at cffi. Does Hunchentoot use CFFI even when SSL is disabled? Should CFFI be compiled when :hunchentoot-no-ssl is on features? CL-USER(4): (asdf:oos 'asdf:load-op 'hunchentoot) ; loading system definition from /home/ocorrait/systems/hunchentoot.asd into # ; registering # as HUNCHENTOOT ; loading system definition from /home/ocorrait/systems/url-rewrite.asd into # ; registering # as URL-REWRITE ; loading system definition from /home/ocorrait/systems/rfc2388.asd into # ; registering # as RFC2388 ; loading system definition from /home/ocorrait/systems/md5.asd into # ; registering # as MD5 ; loading system definition from /home/ocorrait/systems/cl+ssl.asd into # ; registering # as CL+SSL ; loading system definition from /home/ocorrait/systems/flexi-streams.asd into # ; registering # as FLEXI-STREAMS ; loading system definition from /home/ocorrait/systems/trivial-gray-streams.asd into # ; registering # as TRIVIAL-GRAY-STREAMS ; loading system definition from /home/ocorrait/systems/cffi.asd into # Error loading /nfs/ck/home/ocorrait/site/cffi_0.9.2/cffi.asd at line 30 (offset 1412) Debugger invoked on condition of type SIMPLE-ERROR: Sorry, this Lisp is not yet supported. Patches welcome! Restarts: 0: TOP-LEVEL Return to top level. [1] ASDF0(5): 0 CL-USER(6): *features* (:ASDF :HUNCHENTOOT-NO-SSL :JAVA-1.4 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :UNIX :SUNOS) regards tiarn?n From edi at agharta.de Wed Nov 28 13:42:07 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 28 Nov 2007 14:42:07 +0100 Subject: [hunchentoot-devel] Hunchentoot on abcl? In-Reply-To: (Tiarnan O'Corrain's message of "Wed, 28 Nov 2007 12:35:40 +0000") References: Message-ID: On Wed, 28 Nov 2007 12:35:40 +0000, "Tiarnan O'Corrain" wrote: > Does Hunchentoot use CFFI even when SSL is disabled? No, it shouldn't. > Should CFFI be compiled when :hunchentoot-no-ssl is on features? Nope. Maybe ABCL has problems with feature expressions? Edi.