From ignas.mikalajunas at gmail.com Tue Dec 2 14:18:30 2008 From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas) Date: Tue, 2 Dec 2008 16:18:30 +0200 Subject: [hunchentoot-devel] different sessions in different tabs In-Reply-To: <24f203480811191039x75d7d3a3t7a935889e25c5193@mail.gmail.com> References: <1423680295@web.de> <24f203480811191039x75d7d3a3t7a935889e25c5193@mail.gmail.com> Message-ID: >> If I start two "sessions" at a hunchentoot page from two different tabs in firefox, the *session* object accessible in the handler is the same for requests from both tabs. I would want to track the sessions separately. >> In a next step I would introduce user authentication, and hope that only one authentication is necessary to start plural sessions from different tabs. >> Is there a standard way to achieve these functionalities ? >> Thank you for your comments. >> Frank >> >> _______ > > Cookies are usually per-browser, not per window. You could probably do > your own sessions and pass around an ID as a GET parameter, though > that would be messy. > > Alternatively, you could have a number of different domains; each > domain would then get a different session. > Rob When debugging applications that use session to track logins, I just add more than one hostname for localhost in my /etc/hosts file like: 127.0.0.1 localhost.localdomain localhost student manager so I can do things like: http://student:8080/ http://manager:8080/ in different tabs, with different sessions. Ignas From ignas.mikalajunas at gmail.com Thu Dec 4 12:08:32 2008 From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas) Date: Thu, 4 Dec 2008 14:08:32 +0200 Subject: [hunchentoot-devel] Deployment In-Reply-To: References: Message-ID: I am using detachtty like this: a "detach" script: #!/bin/sh prefix="$1" program="`which "$2"`" shift 2 /usr/bin/detachtty --dribble-file "$prefix.dribble" --log-file "$prefix.log" --pid-file "$prefix.dribble" "$prefix.socket" "$program" "$@" and the way to load it ~/usr/bin/detach sbcl sbcl --eval "(load \"start.lisp\")" and have it in crontab so it would go up every reboot (i don't have a root on that machine) Ignas From info at jensteich.de Thu Dec 4 15:29:24 2008 From: info at jensteich.de (Jens Teich) Date: Thu, 04 Dec 2008 16:29:24 +0100 Subject: [hunchentoot-devel] Logfile question: double entries Message-ID: <4937F754.6010409@jensteich.de> When I browse to http://localhost:4242/cat?lang=de&aktion=START in my hunchentoot application, I find two entries in the logfile: [2008-12-04 16:23:55] 127.0.0.1 - "GET /cat?lang=de&aktion=START HTTP/1.1" 200 20493 "http://localhost:4242/cat?lang=de&aktion=LOGOUT" "Mozilla ... [2008-12-04 16:23:55] 127.0.0.1 - "GET /cat?lang=de&aktion=START HTTP/1.1" 200 20493 "http://localhost:4242/cat?lang=de&aktion=START" "Mozilla ... Should I worry about that? I am using sessions and I am still using version 0.15.6. Other question: how do I turn off the logfile in a standalone hunchentoot app? Jens From vseloved at gmail.com Fri Dec 5 00:32:14 2008 From: vseloved at gmail.com (Vsevolod) Date: Fri, 5 Dec 2008 02:32:14 +0200 Subject: [hunchentoot-devel] minor modification to HANDLE-STATIC-FILE Message-ID: <89dc7c5b0812041632o3931a0beg2f18d93640edc2e5@mail.gmail.com> I thought, that it would be useful (especially in dynamic REST-style handlers, which create the files on the fly) to handle files with the appropriate header set, i.e.: Content-Disposition: attachment; filename="..." the diff is attached -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From sblist at me.com Fri Dec 5 01:04:48 2008 From: sblist at me.com (Scott Bell) Date: Thu, 04 Dec 2008 19:04:48 -0600 Subject: [hunchentoot-devel] TCP Input timeout on CCL Message-ID: <18472FD2-4930-415F-877D-BCD0DB2B502A@me.com> Hi folks, We have an application using Hunchentoot currently running on SBCL and Allegro, and we're investigating the possibility of using CCL additionally. I'm able to get the application up and running, but after each web request (which is successful, from the perspective of the client), I receive the following in the debugger: Input timeout on # [Condition of type INPUT-TIMEOUT] Has anyone else encountered this before or have any idea on how to proceed with resolving the issue? Thanks, - Scott Bell From hans at huebner.org Fri Dec 5 06:50:33 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 5 Dec 2008 07:50:33 +0100 Subject: [hunchentoot-devel] TCP Input timeout on CCL In-Reply-To: <18472FD2-4930-415F-877D-BCD0DB2B502A@me.com> References: <18472FD2-4930-415F-877D-BCD0DB2B502A@me.com> Message-ID: On Fri, Dec 5, 2008 at 02:04, Scott Bell wrote: > Hi folks, > > We have an application using Hunchentoot currently running on SBCL and > Allegro, and we're investigating the possibility of using CCL > additionally. I'm > able to get the application up and running, but after each web request > (which > is successful, from the perspective of the client), I receive the > following in the > debugger: > > Input timeout on # #x30004277FD9D> > [Condition of type INPUT-TIMEOUT] > > Has anyone else encountered this before or have any idea on how to > proceed with resolving the issue? This happens when a connection times out - It is "normal", but the condition is not properly caught in the worker thread function. We will fix the problem in the upcoming (!) release, but until then, you can just ignore it. Do you use the release or the development version of Hunchentoot? -Hans From rflug05 at gmail.com Fri Dec 5 07:31:58 2008 From: rflug05 at gmail.com (Nick Allen) Date: Fri, 5 Dec 2008 08:31:58 +0100 Subject: [hunchentoot-devel] Deployment In-Reply-To: References: Message-ID: we used AWS. initially we used screen, but eventually we had the AWS image start daemontools, which started lisp. after a while we switched from daemontools to some debian or ubuntu equivalent, I don't remember the name one way or the other, the important thing is to make sure swank also gets started so you can connect remotely with SLIME/Emacs ;-) we used hunchentoot behind NGINX, which worked like a charm (much easier than apache) take care Nick On Thu, Dec 4, 2008 at 1:08 PM, Ignas Mikalajunas wrote: > I am using detachtty like this: > > a "detach" script: > #!/bin/sh > prefix="$1" > program="`which "$2"`" > shift 2 > /usr/bin/detachtty --dribble-file "$prefix.dribble" --log-file > "$prefix.log" --pid-file "$prefix.dribble" "$prefix.socket" "$program" > "$@" > > and the way to load it > > ~/usr/bin/detach sbcl sbcl --eval "(load \"start.lisp\")" > > and have it in crontab so it would go up every reboot (i don't have a > root on that machine) > > Ignas > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From edi at agharta.de Fri Dec 5 08:41:39 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 05 Dec 2008 09:41:39 +0100 Subject: [hunchentoot-devel] Logfile question: double entries In-Reply-To: <4937F754.6010409@jensteich.de> (Jens Teich's message of "Thu, 04 Dec 2008 16:29:24 +0100") References: <4937F754.6010409@jensteich.de> Message-ID: On Thu, 04 Dec 2008 16:29:24 +0100, Jens Teich wrote: > When I browse to http://localhost:4242/cat?lang=de&aktion=START in my > hunchentoot application, I find two entries in the logfile: > > [2008-12-04 16:23:55] 127.0.0.1 - "GET /cat?lang=de&aktion=START > HTTP/1.1" 200 20493 "http://localhost:4242/cat?lang=de&aktion=LOGOUT" > "Mozilla ... > > [2008-12-04 16:23:55] 127.0.0.1 - "GET /cat?lang=de&aktion=START > HTTP/1.1" 200 20493 "http://localhost:4242/cat?lang=de&aktion=START" > "Mozilla ... > > Should I worry about that? I'd say this shouldn't happen. Can you use a packet sniffer to check if the browser really makes two requests? > Other question: how do I turn off the logfile in a standalone > hunchentoot app? http://weitz.de/hunchentoot/#*show-access-log-messages* From edi at agharta.de Fri Dec 5 08:39:26 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 05 Dec 2008 09:39:26 +0100 Subject: [hunchentoot-devel] minor modification to HANDLE-STATIC-FILE In-Reply-To: <89dc7c5b0812041632o3931a0beg2f18d93640edc2e5@mail.gmail.com> (Vsevolod's message of "Fri, 5 Dec 2008 02:32:14 +0200") References: <89dc7c5b0812041632o3931a0beg2f18d93640edc2e5@mail.gmail.com> Message-ID: On Fri, 5 Dec 2008 02:32:14 +0200, Vsevolod wrote: > I thought, that it would be useful (especially in dynamic REST-style > handlers, which create the files on the fly) to handle files with > the appropriate header set, i.e.: Content-Disposition: attachment; > filename="..." I don't think it is a good idea to do this unconditionally. From vseloved at gmail.com Fri Dec 5 10:38:10 2008 From: vseloved at gmail.com (Vsevolod) Date: Fri, 5 Dec 2008 12:38:10 +0200 Subject: [hunchentoot-devel] minor modification to HANDLE-STATIC-FILE In-Reply-To: References: <89dc7c5b0812041632o3931a0beg2f18d93640edc2e5@mail.gmail.com> Message-ID: <89dc7c5b0812050238m14f14be2w5d33f266a9197ea7@mail.gmail.com> Than, maybe add optional parameter to HANDLE-STATIC-FILE? (defun handle-static-file (path &optional content-type filename) "A function which acts like a Hunchentoot handler for the file denoted by PATH. Send a content type header corresponding to CONTENT-TYPE or \(if that is NIL) tries to determine the content type via the file's suffix. If FILENAME isn't NIL, send Content-disposition header with filename set to either FILENAME (if it's a string) or real FILE-NAMESTRING" <...> (setf (header-out "Last-Modified") (rfc-1123-date time) (content-length) (file-length file)) (when filename (setf (header-out "Content-disposition") (format nil "attachement; filename=\"~a\"" (if (stringp filename) filename (file-namestring path)))) <...> On 12/5/08, Edi Weitz wrote: > On Fri, 5 Dec 2008 02:32:14 +0200, Vsevolod wrote: > >> I thought, that it would be useful (especially in dynamic REST-style >> handlers, which create the files on the fly) to handle files with >> the appropriate header set, i.e.: Content-Disposition: attachment; >> filename="..." > > I don't think it is a good idea to do this unconditionally. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- vsevolod From edi at agharta.de Fri Dec 5 12:04:51 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 05 Dec 2008 13:04:51 +0100 Subject: [hunchentoot-devel] minor modification to HANDLE-STATIC-FILE In-Reply-To: <89dc7c5b0812050238m14f14be2w5d33f266a9197ea7@mail.gmail.com> (Vsevolod's message of "Fri, 5 Dec 2008 12:38:10 +0200") References: <89dc7c5b0812041632o3931a0beg2f18d93640edc2e5@mail.gmail.com> <89dc7c5b0812050238m14f14be2w5d33f266a9197ea7@mail.gmail.com> Message-ID: On Fri, 5 Dec 2008 12:38:10 +0200, Vsevolod wrote: > Than, maybe add optional parameter to HANDLE-STATIC-FILE? Yeah, maybe something like that. But in that case I'd use keywords and not optional arguments. I'm not sure if that's really so useful, though. What do others think? From hans at huebner.org Fri Dec 5 12:38:34 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 5 Dec 2008 13:38:34 +0100 Subject: [hunchentoot-devel] minor modification to HANDLE-STATIC-FILE In-Reply-To: References: <89dc7c5b0812041632o3931a0beg2f18d93640edc2e5@mail.gmail.com> <89dc7c5b0812050238m14f14be2w5d33f266a9197ea7@mail.gmail.com> Message-ID: On Fri, Dec 5, 2008 at 13:04, Edi Weitz wrote: > On Fri, 5 Dec 2008 12:38:10 +0200, Vsevolod wrote: > >> Than, maybe add optional parameter to HANDLE-STATIC-FILE? > > Yeah, maybe something like that. But in that case I'd use keywords > and not optional arguments. > > I'm not sure if that's really so useful, though. What do others > think? I think that the content disposition is application specific. I'd not put it into handle-static-file. Applications can always use their own handler function to set up appropriate headers, then call handle-static-file to do the gruntwork. -Hans From info at jensteich.de Fri Dec 5 13:23:23 2008 From: info at jensteich.de (Jens Teich) Date: Fri, 05 Dec 2008 14:23:23 +0100 Subject: [hunchentoot-devel] Logfile question: double entries In-Reply-To: References: <4937F754.6010409@jensteich.de> Message-ID: <49392B4B.80007@jensteich.de> Edi Weitz schrieb: > Can you use a packet sniffer to check > if the browser really makes two requests? I have a testing network setup with two computers host (webserver) 192.168.2.101 (Win XP) client 192.168.2.100 (Mac OS 10.5) Client (FF[*]) calls http://192.168.2.101:4242/cat?lang=fr&aktion=start Hunchentoot logfile entry is: [2008-12-05 14:13:40] 192.168.2.100 - "GET /cat?lang=fr&aktion=START HTTP/1.1" 200 21196 "http://192.168.2.101:4242/cat?lang=fr&aktion=START" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" [2008-12-05 14:13:40] 192.168.2.100 - "GET /cat?lang=fr&aktion=START HTTP/1.1" 200 21196 "http://192.168.2.101:4242/cat?lang=fr&aktion=START" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" [2008-12-05 14:13:40 [ERROR]] Error while processing connection: Error during socket operation in # : Eine bestehende Verbindung wurde softwaregesteuert durch den Hostcomputer abgebrochen. windump on host listening for client gives C:\Dokumente und Einstellungen\JensTeich\Desktop>WinDump.exe -i 3 host 192.168.2.100 WinDump.exe: listening on \Device\NPF_{22723770-2B8B-443A-8B18-B081115D9396} 14:13:40.345608 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : S 2046829756:2046829756(0) win 65535 14:13:40.345701 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : S 997426145:997426145(0) ack 2046829757 win 65535 14:13:40.348258 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 1 win 65535 14:13:40.348434 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : P 1:763(762) ack 1 win 65535 14:13:40.441134 IP LENOVO-JENS.Speedport_W_502V_Typ_A.137 > 192.168.2.100.137: U DP, length 50 14:13:40.443273 IP 192.168.2.100 > LENOVO-JENS.Speedport_W_502V_Typ_A: ICMP 192. 168.2.100 udp port 137 unreachable, length 36 14:13:40.511255 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 1:1261(1260) ack 763 win 45799 14:13:40.511379 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 1261:2521(1260) ack 763 win 45799 14:13:40.755614 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 2521 win 65535 14:13:40.755659 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 2521:3781(1260) ack 763 win 45799 14:13:40.755780 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 3781:5041(1260) ack 763 win 45799 14:13:40.755848 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 5041:6301(1260) ack 763 win 45799 14:13:40.759604 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 5041 win 65520 14:13:40.759626 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 6301:7561(1260) ack 763 win 45799 14:13:40.759712 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : P 7561:8821(1260) ack 763 win 45799 14:13:40.759781 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 8821:10081(1260) ack 763 win 45799 14:13:40.762656 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 7561 win 65520 14:13:40.762684 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 10081:11341(1260) ack 763 win 45799 14:13:40.762780 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 11341:12601(1260) ack 763 win 45799 14:13:40.762843 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 12601:13861(1260) ack 763 win 45799 14:13:40.762922 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 8821 win 65520 14:13:40.762948 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 13861:15121(1260) ack 763 win 45799 14:13:40.763011 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 15121:16381(1260) ack 763 win 45799 14:13:40.767150 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 11341 win 65535 14:13:40.767176 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : P 16381:17641(1260) ack 763 win 45799 14:13:40.767262 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 17641:18901(1260) ack 763 win 45799 14:13:40.767343 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 18901:20161(1260) ack 763 win 45799 14:13:40.767451 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 13861 win 65535 14:13:40.767473 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 20161:21421(1260) ack 763 win 45799 14:13:40.767536 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : P 21421:21575(154) ack 763 win 45799 14:13:40.768020 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 16381 win 65535 14:13:40.771291 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 17641 win 65520 14:13:40.772353 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 20161 win 65520 14:13:40.772644 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 21575 win 65535 14:13:40.820761 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : P 763:1495(732) ack 21575 win 65535 14:13:40.894308 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 21575:22835(1260) ack 1495 win 45990 14:13:40.894465 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 22835:24095(1260) ack 1495 win 45990 14:13:40.894515 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 24095:25355(1260) ack 1495 win 45990 14:13:40.894563 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 25355:26615(1260) ack 1495 win 45990 14:13:40.894610 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 26615:27875(1260) ack 1495 win 45990 14:13:40.894658 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 27875:29135(1260) ack 1495 win 45990 14:13:40.894705 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : P 29135:29767(632) ack 1495 win 45990 14:13:40.894776 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 29767:31027(1260) ack 1495 win 45990 14:13:40.894825 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 31027:32287(1260) ack 1495 win 45990 14:13:40.894872 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 32287:33547(1260) ack 1495 win 45990 14:13:40.894919 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 33547:34807(1260) ack 1495 win 45990 14:13:40.894966 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 34807:36067(1260) ack 1495 win 45990 14:13:40.899155 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : . ack 24095 win 65535 14:13:40.899185 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . 36067:37327(1260) ack 1495 win 45990 14:13:40.899267 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : P 37327:37959(632) ack 1495 win 45990 14:13:40.902459 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : F 1495:1495(0) ack 25355 win 65535 14:13:40.902484 IP LENOVO-JENS.Speedport_W_502V_Typ_A.4242 > 192.168.2.100.49383 : . ack 1496 win 45990 14:13:40.902660 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.906996 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.907149 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.909107 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.909410 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.912076 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.912389 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.912600 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.912800 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.913071 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.913204 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831251:2046831251(0) win 0 14:13:40.913365 IP 192.168.2.100.49383 > LENOVO-JENS.Speedport_W_502V_Typ_A.4242 : R 2046831252:2046831252(0) win 0 14:13:41.927748 IP LENOVO-JENS.Speedport_W_502V_Typ_A.137 > 192.168.2.100.137: U DP, length 50 14:13:41.932071 IP 192.168.2.100 > LENOVO-JENS.Speedport_W_502V_Typ_A: ICMP 192. 168.2.100 udp port 137 unreachable, length 36 14:13:43.427864 IP LENOVO-JENS.Speedport_W_502V_Typ_A.137 > 192.168.2.100.137: U DP, length 50 14:13:43.431725 IP 192.168.2.100 > LENOVO-JENS.Speedport_W_502V_Typ_A: ICMP 192. 168.2.100 udp port 137 unreachable, length 36 68 packets captured 77 packets received by filter 0 packets dropped by kernel Thanks for your help [*] Problem seems to be browser dependent. Safari does not produce double logfile entries Jens From rsynnott at gmail.com Fri Dec 5 15:18:25 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Fri, 5 Dec 2008 15:18:25 +0000 Subject: [hunchentoot-devel] Logfile question: double entries In-Reply-To: <49392B4B.80007@jensteich.de> References: <4937F754.6010409@jensteich.de> <49392B4B.80007@jensteich.de> Message-ID: <24f203480812050718g238d5ff1j3f35455dd56b3708@mail.gmail.com> 2008/12/5 Jens Teich : > Edi Weitz schrieb: >> Can you use a packet sniffer to check >> if the browser really makes two requests? > > I have a testing network setup with two computers > host (webserver) 192.168.2.101 (Win XP) > client 192.168.2.100 (Mac OS 10.5) > > Client (FF[*]) calls http://192.168.2.101:4242/cat?lang=fr&aktion=start > .. Hmm, now that I think of it, I think I've seen Firefox do this, too. Some sort of prefetching thing gone wrong, perhaps? Rob From vseloved at gmail.com Fri Dec 5 16:22:41 2008 From: vseloved at gmail.com (Vsevolod) Date: Fri, 5 Dec 2008 18:22:41 +0200 Subject: [hunchentoot-devel] minor modification to HANDLE-STATIC-FILE In-Reply-To: References: <89dc7c5b0812041632o3931a0beg2f18d93640edc2e5@mail.gmail.com> <89dc7c5b0812050238m14f14be2w5d33f266a9197ea7@mail.gmail.com> Message-ID: <89dc7c5b0812050822h538070f0m3702fa57dd3d9047@mail.gmail.com> That is a valid claim, I agree. I overlooked this possibility of modifying the headers before calling HANDLE-STATIC-FILE. Thanks On 12/5/08, Hans H?bner wrote: > On Fri, Dec 5, 2008 at 13:04, Edi Weitz wrote: >> On Fri, 5 Dec 2008 12:38:10 +0200, Vsevolod wrote: >> >>> Than, maybe add optional parameter to HANDLE-STATIC-FILE? >> >> Yeah, maybe something like that. But in that case I'd use keywords >> and not optional arguments. >> >> I'm not sure if that's really so useful, though. What do others >> think? > > I think that the content disposition is application specific. I'd not > put it into handle-static-file. Applications can always use their own > handler function to set up appropriate headers, then call > handle-static-file to do the gruntwork. > > -Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- vsevolod From sblist at me.com Fri Dec 5 17:33:06 2008 From: sblist at me.com (sblist at me.com) Date: Fri, 05 Dec 2008 11:33:06 -0600 Subject: [hunchentoot-devel] TCP Input timeout on CCL References: <47AB15BD-E4F3-42C8-8761-915D7E339B7C@me.com> Message-ID: <1C55A036-9425-4614-8621-F1A7CBFBCDC4@me.com> Hi Hans, On 5-Dec-08, at 12:50 AM, Hans H?bner wrote: > This happens when a connection times out - It is "normal", but the > condition is not properly caught in the worker thread function. We > will fix the problem in the upcoming (!) release, but until then, you > can just ignore it. Do you use the release or the development version > of Hunchentoot? We are using the latest release at the moment. Would you recommend trying out the development version? Where could that be obtained? Thanks for your help, - Scott From hans at huebner.org Fri Dec 5 18:21:03 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 5 Dec 2008 19:21:03 +0100 Subject: [hunchentoot-devel] TCP Input timeout on CCL In-Reply-To: <1C55A036-9425-4614-8621-F1A7CBFBCDC4@me.com> References: <47AB15BD-E4F3-42C8-8761-915D7E339B7C@me.com> <1C55A036-9425-4614-8621-F1A7CBFBCDC4@me.com> Message-ID: Scott, the development version of Hunchentoot can be obtained by svn co svn://bknr.net/trunk/ediware This will also check out the updated versions of Hunchentoot's dependencies. The new version is not yet finished, and it is not API compatible. You need to spend some time on converting your application. We have scheduled a release engineering session for Hunchentoot in January, but please do not hold your breath. -Hans On Fri, Dec 5, 2008 at 18:33, wrote: > Hi Hans, > > On 5-Dec-08, at 12:50 AM, Hans H?bner wrote: > >> This happens when a connection times out - It is "normal", but the >> condition is not properly caught in the worker thread function. We >> will fix the problem in the upcoming (!) release, but until then, you >> can just ignore it. Do you use the release or the development version >> of Hunchentoot? > > We are using the latest release at the moment. Would you recommend > trying out the development version? Where could that be obtained? > > Thanks for your help, > > - Scott > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From info at jensteich.de Sat Dec 6 15:28:37 2008 From: info at jensteich.de (Jens Teich) Date: Sat, 06 Dec 2008 16:28:37 +0100 Subject: [hunchentoot-devel] Logfile question: double entries In-Reply-To: <24f203480812050718g238d5ff1j3f35455dd56b3708@mail.gmail.com> References: <4937F754.6010409@jensteich.de> <49392B4B.80007@jensteich.de> <24f203480812050718g238d5ff1j3f35455dd56b3708@mail.gmail.com> Message-ID: <493A9A25.7050805@jensteich.de> Robert Synnott schrieb: > 2008/12/5 Jens Teich : >> Edi Weitz schrieb: >>> Can you use a packet sniffer to check >>> if the browser really makes two requests? >> I have a testing network setup with two computers >> host (webserver) 192.168.2.101 (Win XP) >> client 192.168.2.100 (Mac OS 10.5) >> >> Client (FF[*]) calls http://192.168.2.101:4242/cat?lang=fr&aktion=start >> > .. > Hmm, now that I think of it, I think I've seen Firefox do this, too. > Some sort of prefetching thing gone wrong, perhaps? > Rob Seems to be a problem of FF. The search terms 'Firefox double requests' give > 4x10^6 hits. Jens From info at jensteich.de Sat Dec 6 15:55:41 2008 From: info at jensteich.de (Jens Teich) Date: Sat, 06 Dec 2008 16:55:41 +0100 Subject: [hunchentoot-devel] Logfile question: double entries In-Reply-To: <24f203480812050718g238d5ff1j3f35455dd56b3708@mail.gmail.com> References: <4937F754.6010409@jensteich.de> <49392B4B.80007@jensteich.de> <24f203480812050718g238d5ff1j3f35455dd56b3708@mail.gmail.com> Message-ID: <493AA07D.8060002@jensteich.de> Robert Synnott schrieb: > 2008/12/5 Jens Teich : >> Edi Weitz schrieb: >>> Can you use a packet sniffer to check >>> if the browser really makes two requests? >> I have a testing network setup with two computers >> host (webserver) 192.168.2.101 (Win XP) >> client 192.168.2.100 (Mac OS 10.5) >> >> Client (FF[*]) calls http://192.168.2.101:4242/cat?lang=fr&aktion=start >> > .. > Hmm, now that I think of it, I think I've seen Firefox do this, too. > Some sort of prefetching thing gone wrong, perhaps? > Rob Problem solved. As mentioned in http://www.markgandolfo.com.au/articles/33, FF retries the request when finding img-tags containing empty sources, ie. . Therapy: removing these empty src attributes. Jens From franks-muc at web.de Mon Dec 8 09:38:46 2008 From: franks-muc at web.de (Frank Schorr) Date: Mon, 08 Dec 2008 10:38:46 +0100 Subject: [hunchentoot-devel] handle-static-file Message-ID: <1456200733@web.de> Made a (create-folder-dispatcher-and-handler "/pdf/" "c:/..../pdf/") When I direct the browser to .../pdf/doesnotexist, the server sends a 404. OK But .../pdf/* generates "illegal use of wild pathname" . Call to INVOKE-DEBUGGER Call to SIGNAL Call to PROBE-FILE Call to HUNCHENTOOT:HANDLE-STATIC-FILE Call to HUNCHENTOOT::PROCESS-REQUEST Call to HUNCHENTOOT::PROCESS-CONNECTION Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) I can handle this on my side, but I think it is a risk. _______________________________________________________________________ Sensationsangebot verl?ngert: WEB.DE FreeDSL - Telefonanschluss + DSL f?r nur 16,37 Euro/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K13805B7069a From hans at huebner.org Mon Dec 8 10:06:56 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 8 Dec 2008 11:06:56 +0100 Subject: [hunchentoot-devel] handle-static-file In-Reply-To: <1456200733@web.de> References: <1456200733@web.de> Message-ID: On Mon, Dec 8, 2008 at 10:38, Frank Schorr wrote: > Made a (create-folder-dispatcher-and-handler "/pdf/" "c:/..../pdf/") > When I direct the browser to .../pdf/doesnotexist, the server sends a 404. OK > But .../pdf/* generates "illegal use of wild pathname" . > > Call to INVOKE-DEBUGGER > Call to SIGNAL > Call to PROBE-FILE > Call to HUNCHENTOOT:HANDLE-STATIC-FILE > Call to HUNCHENTOOT::PROCESS-REQUEST > Call to HUNCHENTOOT::PROCESS-CONNECTION > Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) > > I can handle this on my side, but I think it is a risk. Why do you think it is a risk? What is risked? -Hans From franks-muc at web.de Mon Dec 8 10:47:42 2008 From: franks-muc at web.de (Frank Schorr) Date: Mon, 08 Dec 2008 11:47:42 +0100 Subject: [hunchentoot-devel] handle-static-file Message-ID: <1456358795@web.de> > -----Urspr?ngliche Nachricht----- > Von: "Hans H?bner" > Gesendet: 08.12.08 11:36:47 > An: "General interest list for Hunchentoot and CL-WEBDAV" > Betreff: Re: [hunchentoot-devel] handle-static-file > On Mon, Dec 8, 2008 at 10:38, Frank Schorr wrote: > > Made a (create-folder-dispatcher-and-handler "/pdf/" "c:/..../pdf/") > > When I direct the browser to .../pdf/doesnotexist, the server sends a 404. OK > > But .../pdf/* generates "illegal use of wild pathname" . > > > > Call to INVOKE-DEBUGGER > > Call to SIGNAL > > Call to PROBE-FILE > > Call to HUNCHENTOOT:HANDLE-STATIC-FILE > > Call to HUNCHENTOOT::PROCESS-REQUEST > > Call to HUNCHENTOOT::PROCESS-CONNECTION > > Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) > > > > I can handle this on my side, but I think it is a risk. > > Why do you think it is a risk? What is risked? > > -Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > The risk is the bad guy sending many of these requests, the server will create a same number of threads, all hanging in the debugger, until a limit is reached. I believe 404 would be the correct response for requesting file "*" which is not present. Frank ____________________________________________________________________ Psssst! Schon vom neuen WEB.DE MultiMessenger geh?rt? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 From hans at huebner.org Mon Dec 8 11:12:49 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 8 Dec 2008 12:12:49 +0100 Subject: [hunchentoot-devel] handle-static-file In-Reply-To: <1456358795@web.de> References: <1456358795@web.de> Message-ID: On Mon, Dec 8, 2008 at 11:47, Frank Schorr wrote: >> > Made a (create-folder-dispatcher-and-handler "/pdf/" "c:/..../pdf/") >> > When I direct the browser to .../pdf/doesnotexist, the server sends a 404. OK >> > But .../pdf/* generates "illegal use of wild pathname" . >> > >> > Call to INVOKE-DEBUGGER >> > Call to SIGNAL >> > Call to PROBE-FILE >> > Call to HUNCHENTOOT:HANDLE-STATIC-FILE >> > Call to HUNCHENTOOT::PROCESS-REQUEST >> > Call to HUNCHENTOOT::PROCESS-CONNECTION >> > Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) >> > >> > I can handle this on my side, but I think it is a risk. >> >> Why do you think it is a risk? What is risked? > The risk is the bad guy sending many of these requests, the server will create a same number of threads, all hanging in the debugger, until a limit is reached. > I believe 404 would be the correct response for requesting file "*" which is not present. I agree that 404 would be a better response, but I don't know about the debugger thing. In production environments, you would not enable the debugger for handling errors in requests. Now, the question is whether what you describe is a misbehaviour in Hunchentoot that sends you to the debugger even though you did not enable debugging. Did you intend to write that? -Hans From franks-muc at web.de Mon Dec 8 12:03:22 2008 From: franks-muc at web.de (Frank Schorr) Date: Mon, 08 Dec 2008 13:03:22 +0100 Subject: [hunchentoot-devel] handle-static-file Message-ID: <1456450494@web.de> > -----Urspr?ngliche Nachricht----- > Von: "Hans H?bner" > Gesendet: 08.12.08 12:32:13 > An: "General interest list for Hunchentoot and CL-WEBDAV" > Betreff: Re: [hunchentoot-devel] handle-static-file > On Mon, Dec 8, 2008 at 11:47, Frank Schorr wrote: > >> > Made a (create-folder-dispatcher-and-handler "/pdf/" "c:/..../pdf/") > >> > When I direct the browser to .../pdf/doesnotexist, the server sends a 404. OK > >> > But .../pdf/* generates "illegal use of wild pathname" . > >> > > >> > Call to INVOKE-DEBUGGER > >> > Call to SIGNAL > >> > Call to PROBE-FILE > >> > Call to HUNCHENTOOT:HANDLE-STATIC-FILE > >> > Call to HUNCHENTOOT::PROCESS-REQUEST > >> > Call to HUNCHENTOOT::PROCESS-CONNECTION > >> > Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) > >> > > >> > I can handle this on my side, but I think it is a risk. > >> > >> Why do you think it is a risk? What is risked? > > The risk is the bad guy sending many of these requests, the server will create a same number of threads, all hanging in the debugger, until a limit is reached. > > I believe 404 would be the correct response for requesting file "*" which is not present. > > I agree that 404 would be a better response, but I don't know about > the debugger thing. In production environments, you would not enable > the debugger for handling errors in requests. > > Now, the question is whether what you describe is a misbehaviour in > Hunchentoot that sends you to the debugger even though you did not > enable debugging. Did you intend to write that? > > -Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > I have debugging enabled, and there is no misbehaviour in Hunchentoot at all. I just wanted to reprort an observation which could result in (avoidable) security problems under particular circumstances. May be I will disable debugging when my website will mature to a production environment with more than 20 friendly users a day. Until then it is my learning environment open to the internet where the debugger is helpfull to understand those errors which should be better handled by my code. The IDE debugger has advantages over analysing logs and logged backtraces. Is it really necessary to disable debugging in the production environment ? The expected information gained from a thread hanging in the IDE debugger can have a higher weight than the fear of the bad guy exploiting the until then not publicly known bug in the application. It would be interesting to have your thoughts on that. Frank ____________________________________________________________________ Psssst! Schon vom neuen WEB.DE MultiMessenger geh?rt? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 From hans at huebner.org Mon Dec 8 12:44:31 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 8 Dec 2008 13:44:31 +0100 Subject: [hunchentoot-devel] handle-static-file In-Reply-To: <1456450494@web.de> References: <1456450494@web.de> Message-ID: On Mon, Dec 8, 2008 at 13:03, Frank Schorr wrote: > Is it really necessary to disable debugging in the production environment ? The expected information gained from a thread hanging in the IDE debugger can have a higher weight than the fear of the bad guy exploiting the until then not publicly known bug in the application. It would be interesting to have your thoughts on that. It is really up to you: If you want to make sure that no bad guy can start an indefinite number of debugger threads, disable debugging. I certainly never run any production system in a mode that makes random Internet requests end up in a new debugger context, but that is just my taste. Going back to your original inquiry: I think that the invalid wildcard pathname error that you've produced deserves better handling. You can try this patch: Index: misc.lisp =================================================================== --- misc.lisp (revision 4116) +++ misc.lisp (working copy) @@ -129,8 +129,9 @@ denoted by PATH. Send a content type header corresponding to CONTENT-TYPE or \(if that is NIL) tries to determine the content type via the file's suffix." - (unless (and (fad:file-exists-p path) - (not (fad:directory-exists-p path))) + (when (or (wild-pathname-p path) + (not (fad:file-exists-p path)) + (fad:directory-exists-p path)) ;; does not exist (setf (return-code) +http-not-found+) (throw 'handler-done nil)) Please give it a try and let me know if it solves the problem for you. -Hans From franks-muc at web.de Mon Dec 8 14:26:03 2008 From: franks-muc at web.de (Frank Schorr) Date: Mon, 08 Dec 2008 15:26:03 +0100 Subject: [hunchentoot-devel] handle-static-file Message-ID: <1456732058@web.de> > -----Urspr?ngliche Nachricht----- > Von: "Hans H?bner" > Gesendet: 08.12.08 14:01:16 > An: "General interest list for Hunchentoot and CL-WEBDAV" > Betreff: Re: [hunchentoot-devel] handle-static-file > On Mon, Dec 8, 2008 at 13:03, Frank Schorr wrote: > > Is it really necessary to disable debugging in the production environment ? The expected information gained from a thread hanging in the IDE debugger can have a higher weight than the fear of the bad guy exploiting the until then not publicly known bug in the application. It would be interesting to have your thoughts on that. > > It is really up to you: If you want to make sure that no bad guy can > start an indefinite number of debugger threads, disable debugging. I > certainly never run any production system in a mode that makes random > Internet requests end up in a new debugger context, but that is just > my taste. > > Going back to your original inquiry: I think that the invalid > wildcard pathname error that you've produced deserves better handling. > You can try this patch: > > Index: misc.lisp > =================================================================== > --- misc.lisp (revision 4116) > +++ misc.lisp (working copy) > @@ -129,8 +129,9 @@ > denoted by PATH. Send a content type header corresponding to > CONTENT-TYPE or \(if that is NIL) tries to determine the content > type via the file's suffix." > - (unless (and (fad:file-exists-p path) > - (not (fad:directory-exists-p path))) > + (when (or (wild-pathname-p path) > + (not (fad:file-exists-p path)) > + (fad:directory-exists-p path)) > ;; does not exist > (setf (return-code) +http-not-found+) > (throw 'handler-done nil)) > > Please give it a try and let me know if it solves the problem for you. > > -Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > Problem solved - Thank you ! Frank ____________________________________________________________________ Psssst! Schon vom neuen WEB.DE MultiMessenger geh?rt? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 From avodonosov at yandex.ru Tue Dec 9 03:22:11 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Tue, 9 Dec 2008 05:22:11 +0200 Subject: [hunchentoot-devel] only simple-string's are allowed for md5:md5sum-sequence Message-ID: <1696330043.20081209052211@yandex.ru> Hello. Huncentoot used md5 library to generate session strings. The function MD5:MD5SUM-SEQUENCE allows only SIMPLE-STRINGs as arguments. Hunchentoot passes result of FORMAT, which is not necessary returns SIMPLE-STRING (although in many implementations it does). In particular just encountered this error when testing Hunchentoot on ECL (with the patch sent by Marko Kocic here: http://common-lisp.net/pipermail/tbnl-devel/2008-November/004474.html) The fix will be as follows: (defun md5-hex (string) "Calculates the md5 sum of the string STRING and returns it as a hex string." (with-output-to-string (s) - (loop for code across (md5:md5sum-sequence string) + (loop for code across (md5:md5sum-sequence (coerce string 'simple-string)) do (format s "~2,'0x" code)))) Best regards, - Anton From hans at huebner.org Tue Dec 9 05:51:15 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 9 Dec 2008 06:51:15 +0100 Subject: [hunchentoot-devel] only simple-string's are allowed for md5:md5sum-sequence In-Reply-To: <1696330043.20081209052211@yandex.ru> References: <1696330043.20081209052211@yandex.ru> Message-ID: Fix applied, thank you. Please send a context diff next time. The ECL patches unfortunately are against the last release version, so we will not be able to include them in the upcoming release which will be based on the development version. Hopefully, someone can supply us with a new change set for ECL after the release. -Hans On Tue, Dec 9, 2008 at 04:22, Anton Vodonosov wrote: > Hello. > > Huncentoot used md5 library to generate session strings. > The function MD5:MD5SUM-SEQUENCE allows only SIMPLE-STRINGs > as arguments. Hunchentoot passes result of FORMAT, which > is not necessary returns SIMPLE-STRING (although in many > implementations it does). > > In particular just encountered this error when testing Hunchentoot > on ECL (with the patch sent by Marko Kocic here: > http://common-lisp.net/pipermail/tbnl-devel/2008-November/004474.html) > > The fix will be as follows: > > (defun md5-hex (string) > "Calculates the md5 sum of the string STRING and returns it as a hex string." > (with-output-to-string (s) > - (loop for code across (md5:md5sum-sequence string) > + (loop for code across (md5:md5sum-sequence (coerce string 'simple-string)) > do (format s "~2,'0x" code)))) > > > Best regards, > - Anton > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From geocar at gmail.com Tue Dec 9 13:20:35 2008 From: geocar at gmail.com (Geo Carncross) Date: Tue, 9 Dec 2008 08:20:35 -0500 Subject: [hunchentoot-devel] only simple-string's are allowed for md5:md5sum-sequence In-Reply-To: References: <1696330043.20081209052211@yandex.ru> Message-ID: <527511140812090520y2a0ccfa7v9218ca1725440f17@mail.gmail.com> On Tue, Dec 9, 2008 at 12:51 AM, Hans H?bner wrote: > The ECL patches unfortunately are against the last release version, so > we will not be able to include them in the upcoming release which will > be based on the development version. Hopefully, someone can supply us > with a new change set for ECL after the release. Could someone update either http://www.weitz.de/hunchentoot/ or http://weitz.de/patches.html to this effect? A short message explaining where the development branch of Hunchentoot is (or how to coordinate development) would have been very helpful. Even a message like "We're not accepting patches for Hunchentoot/this version is obsolete" would be nice, or at the very least, a "please check with the mailing list before writing any code targetting Hunchentoot". I spent a fair amount of time porting ECL to Hunchentoot (and porting Hunchentoot's dependencies to ECL) only to discover it was wasted efforts in a similar way. Having some big friendly letters explaining how to get this "development version" on the Hunchentoot website would have saved my time, and clearly others. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sblist at me.com Sat Dec 13 20:26:46 2008 From: sblist at me.com (sblist at me.com) Date: Sat, 13 Dec 2008 13:26:46 -0700 Subject: [hunchentoot-devel] TCP Input timeout on CCL In-Reply-To: References: <47AB15BD-E4F3-42C8-8761-915D7E339B7C@me.com> <1C55A036-9425-4614-8621-F1A7CBFBCDC4@me.com> Message-ID: Hans, We might not be ready to jump to the development version just yet, but here's the simple fix to resolve the issue in the current release: --- headers-other.lisp 2008-12-12 16:10:31.000000000 -0700 +++ headers.lisp 2008-12-12 15:49:15.000000000 -0700 @@ -281,6 +281,7 @@ (read-line* *hunchentoot-stream*) ((or end-of-file #+:sbcl sb-sys:io-timeout + #+:ccl ccl:input-timeout #+:cmu sys:io-timeout #+:allegro excl:socket-error) () nil))))) Thanks for all of the help, - Scott On 5-Dec-08, at 11:21 AM, Hans H?bner wrote: > Scott, > > the development version of Hunchentoot can be obtained by > > svn co svn://bknr.net/trunk/ediware > > This will also check out the updated versions of Hunchentoot's > dependencies. The new version is not yet finished, and it is not API > compatible. You need to spend some time on converting your > application. We have scheduled a release engineering session for > Hunchentoot in January, but please do not hold your breath. > > -Hans > From info at jensteich.de Tue Dec 16 08:54:27 2008 From: info at jensteich.de (Jens Teich) Date: Tue, 16 Dec 2008 09:54:27 +0100 Subject: [hunchentoot-devel] long living session Message-ID: <49476CC3.5040608@jensteich.de> I don't get it from the documentation. Sorry for the dumb question. How do I create a session whose cookie does not expire when I close the browser? Still on hunchentoot 0.15.6. Thanks Jens From sky at viridian-project.de Tue Dec 16 10:10:02 2008 From: sky at viridian-project.de (Leslie P. Polzer) Date: Tue, 16 Dec 2008 11:10:02 +0100 (CET) Subject: [hunchentoot-devel] long living session In-Reply-To: <49476CC3.5040608@jensteich.de> References: <49476CC3.5040608@jensteich.de> Message-ID: <62908.88.73.208.85.1229422202.squirrel@mail.stardawn.org> > I don't get it from the documentation. Sorry for the dumb question. > > How do I create a session whose cookie does not expire when I close the > browser? > > Still on hunchentoot 0.15.6. There doesn't seem to be a built-in way to do that. START-SESSION sets a cookie with :EXPIRES NIL, which probably means "when the browser is closed". Define your own START-SESSION to pass a custom timeout. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From info at jensteich.de Wed Dec 17 10:06:49 2008 From: info at jensteich.de (Jens Teich) Date: Wed, 17 Dec 2008 11:06:49 +0100 Subject: [hunchentoot-devel] long living session In-Reply-To: <62908.88.73.208.85.1229422202.squirrel@mail.stardawn.org> References: <49476CC3.5040608@jensteich.de> <62908.88.73.208.85.1229422202.squirrel@mail.stardawn.org> Message-ID: <4948CF39.6090706@jensteich.de> Leslie P. Polzer schrieb: > There doesn't seem to be a built-in way to do that. > > START-SESSION sets a cookie with :EXPIRES NIL, which probably means > "when the browser is closed". Define your own START-SESSION to > pass a custom timeout. Thanks for the hint. I did it exactly that way and it solved the problem. Jens From edi at agharta.de Wed Dec 17 11:18:02 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 17 Dec 2008 12:18:02 +0100 Subject: [hunchentoot-devel] long living session In-Reply-To: <4948CF39.6090706@jensteich.de> (Jens Teich's message of "Wed, 17 Dec 2008 11:06:49 +0100") References: <49476CC3.5040608@jensteich.de> <62908.88.73.208.85.1229422202.squirrel@mail.stardawn.org> <4948CF39.6090706@jensteich.de> Message-ID: On Wed, 17 Dec 2008 11:06:49 +0100, Jens Teich wrote: > Leslie P. Polzer schrieb: >> There doesn't seem to be a built-in way to do that. >> >> START-SESSION sets a cookie with :EXPIRES NIL, which probably means >> "when the browser is closed". Define your own START-SESSION to pass >> a custom timeout. > > Thanks for the hint. I did it exactly that way and it solved the > problem. I would do it a bit differently, but that's a matter of taste. For me, a "session" isn't something that should continue to exist if the user closes the browser or comes back after a week. What I would do in this case (and have done in others) is to give them a long living cookie and automatically open a new session when they come back and the cookie is recognized. That also has the added benefit that whatever is tied to the old session can be cleaned up and doesn't hang around indefinitely. But, as I said, tastes differ. Edi. From ch-tbnl at bobobeach.com Wed Dec 24 16:57:15 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Wed, 24 Dec 2008 08:57:15 -0800 Subject: [hunchentoot-devel] hunchentoot errors Message-ID: <466F62FB-B540-4422-8C44-7869A910EFF7@bobobeach.com> so, just when I managed to squash one persistent failure (running out of threads due to sb-ext:run-process not returning), I seem to have awoken another. I've got two, possibly unrelated, issues. First, the more benign one: I see the following message quite often in the logs: [2008-12-23 18:47:38 [ERROR]] Error while processing connection: The value 1058 is not of type (MOD 1025). occasionally the message is: [2008-12-23 18:46:06 [ERROR]] Error while processing connection: The value 1065 is not of type (UNSIGNED-BYTE 10). any idea where these might be coming from? The second, more serious, problem is that I seem to end up in ldb after a few days of usage: * Argh! corrupted error depth, halting fatal error encountered in SBCL pid 60417(tid 134658560): %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Argh! corrupted error depth, halting fatal error encountered in SBCL pid 60417(tid 134659072): %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Argh! corrupted error depth, halting fatal error encountered in SBCL pid 60417(tid 136982272): %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> > This is a fairly unhelpful error, but I'm wondering if the above- mentioned error isn't tickling some bug in the sbcl/freebsd error handling code. This ldb droppage is fairly new, AFAICT. There have certainly been other failure modes, but this one is new and I'm wondering if might be due to recent changes in either SBCL or hunchentoot. In any event, I'll try to get some more info from ldb to see if I can track this down. Cyrus From ch-tbnl at bobobeach.com Wed Dec 24 19:09:46 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Wed, 24 Dec 2008 11:09:46 -0800 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: <466F62FB-B540-4422-8C44-7869A910EFF7@bobobeach.com> References: <466F62FB-B540-4422-8C44-7869A910EFF7@bobobeach.com> Message-ID: <42CE9B2D-D8B0-4A39-8628-502BFA0FCEE8@bobobeach.com> FWIW, here's a backtrace: 0: Foreign function ldb_monitor, fp = 0x2ad87f98, ra = 0x8055be3 1: Foreign function lose, fp = 0x2ad87fb8, ra = 0x80534ef 2: Foreign function handle_trap, fp = 0x2ad88028, ra = 0x80552c9 3: Foreign fp = 0x2ad8837c, ra = 0xbfbfff94 4: SB-KERNEL::INTERNAL-ERROR 5: Foreign function call_into_lisp, fp = 0x2ad88438, ra = 0x806041c 6: Foreign function funcall2, fp = 0x2ad88458, ra = 0x805113c 7: Foreign function interrupt_internal_error, fp = 0x2ad884a8, ra = 0x8053bef 8: Foreign function handle_trap, fp = 0x2ad88518, ra = 0x8055201 9: Foreign fp = 0x2ad88868, ra = 0xbfbfff94 10: SB-IMPL::REFILL-INPUT-BUFFER 11: SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE 12: (SB-C::HAIRY-ARG-PROCESSOR CHUNGA::READ-CHAR*) 13: (SB-C::HAIRY-ARG-PROCESSOR CHUNGA::READ-LINE*) 14: (SB-C::HAIRY-ARG-PROCESSOR HUNCHENTOOT-CGI::HANDLE-CGI-SCRIPT) 15: HUNCHENTOOT::PROCESS-REQUEST 16: (SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION (COMMON- LISP::T COMMON-LISP::T)) 17: (SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION KEYWORD::AROUND (COMMON-LISP::T COMMON-LISP::T)) 18: (COMMON-LISP::FLET SB-THREAD::WITH-MUTEX-THUNK) 19: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477) 20: SB-THREAD::CALL-WITH-MUTEX 21: (COMMON-LISP::LAMBDA ()) 22: Foreign function call_into_lisp, fp = 0x2ad88f58, ra = 0x806041c 23: Foreign function funcall0, fp = 0x2ad88f78, ra = 0x80510fe 24: Foreign function new_thread_trampoline, fp = 0x2ad88f98, ra = 0x8059985 25: Foreign function _pthread_create, fp = 0x2ad88fe8, ra = 0x2809d5cf On Dec 24, 2008, at 8:57 AM, Cyrus Harmon wrote: > so, just when I managed to squash one persistent failure (running out > of threads due to sb-ext:run-process not returning), I seem to have > awoken another. I've got two, possibly unrelated, issues. First, the > more benign one: > > I see the following message quite often in the logs: > > [2008-12-23 18:47:38 [ERROR]] Error while processing connection: The > value 1058 > is > not of type > > (MOD 1025). > occasionally the message is: > > [2008-12-23 18:46:06 [ERROR]] Error while processing connection: The > value 1065 > is > not of type > > (UNSIGNED-BYTE > > 10). > > any idea where these might be coming from? > > The second, more serious, problem is that I seem to end up in ldb > after a few days of usage: > > * Argh! corrupted error depth, halting > fatal error encountered in SBCL pid 60417(tid 134658560): > %PRIMITIVE HALT called; the party is over. > > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> Argh! corrupted error depth, halting > fatal error encountered in SBCL pid 60417(tid 134659072): > %PRIMITIVE HALT called; the party is over. > > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> Argh! corrupted error depth, halting > fatal error encountered in SBCL pid 60417(tid 136982272): > %PRIMITIVE HALT called; the party is over. > > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> > > > > This is a fairly unhelpful error, but I'm wondering if the above- > mentioned error isn't tickling some bug in the sbcl/freebsd error > handling code. This ldb droppage is fairly new, AFAICT. There have > certainly been other failure modes, but this one is new and I'm > wondering if might be due to recent changes in either SBCL or > hunchentoot. In any event, I'll try to get some more info from ldb to > see if I can track this down. > > Cyrus > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans.huebner at gmail.com Thu Dec 25 08:58:18 2008 From: hans.huebner at gmail.com (Hans Huebner) Date: Thu, 25 Dec 2008 09:58:18 +0100 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: <42CE9B2D-D8B0-4A39-8628-502BFA0FCEE8@bobobeach.com> References: <466F62FB-B540-4422-8C44-7869A910EFF7@bobobeach.com> <42CE9B2D-D8B0-4A39-8628-502BFA0FCEE8@bobobeach.com> Message-ID: Slyrus, from looking at the failure description and the stack backtrace, I would think that the root cause of the problem is in the FreeBSD port of SBCL, maybe related to signal handling with subprocesses. I know that this is not a very satisfying response. Maybe you can try to verify that subprocess handling works properly in a multithreaded environment by spawning a lot of them from multiple threads, in a loop, and see if that triggers the same problem. -Hans On Wed, Dec 24, 2008 at 20:09, Cyrus Harmon wrote: > FWIW, > > here's a backtrace: > > 0: Foreign function ldb_monitor, fp = 0x2ad87f98, ra = 0x8055be3 > 1: Foreign function lose, fp = 0x2ad87fb8, ra = 0x80534ef > 2: Foreign function handle_trap, fp = 0x2ad88028, ra = 0x80552c9 > 3: Foreign fp = 0x2ad8837c, ra = 0xbfbfff94 > 4: SB-KERNEL::INTERNAL-ERROR > 5: Foreign function call_into_lisp, fp = 0x2ad88438, ra = 0x806041c > 6: Foreign function funcall2, fp = 0x2ad88458, ra = 0x805113c > 7: Foreign function interrupt_internal_error, fp = 0x2ad884a8, ra > = 0x8053bef > 8: Foreign function handle_trap, fp = 0x2ad88518, ra = 0x8055201 > 9: Foreign fp = 0x2ad88868, ra = 0xbfbfff94 > 10: SB-IMPL::REFILL-INPUT-BUFFER > 11: SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE > 12: (SB-C::HAIRY-ARG-PROCESSOR CHUNGA::READ-CHAR*) > 13: (SB-C::HAIRY-ARG-PROCESSOR CHUNGA::READ-LINE*) > 14: (SB-C::HAIRY-ARG-PROCESSOR HUNCHENTOOT-CGI::HANDLE-CGI-SCRIPT) > 15: HUNCHENTOOT::PROCESS-REQUEST > 16: (SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION (COMMON- > LISP::T COMMON-LISP::T)) > 17: (SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION > KEYWORD::AROUND (COMMON-LISP::T COMMON-LISP::T)) > 18: (COMMON-LISP::FLET SB-THREAD::WITH-MUTEX-THUNK) > 19: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477) > 20: SB-THREAD::CALL-WITH-MUTEX > 21: (COMMON-LISP::LAMBDA ()) > 22: Foreign function call_into_lisp, fp = 0x2ad88f58, ra = 0x806041c > 23: Foreign function funcall0, fp = 0x2ad88f78, ra = 0x80510fe > 24: Foreign function new_thread_trampoline, fp = 0x2ad88f98, ra = > 0x8059985 > 25: Foreign function _pthread_create, fp = 0x2ad88fe8, ra = > 0x2809d5cf > > > On Dec 24, 2008, at 8:57 AM, Cyrus Harmon wrote: > >> so, just when I managed to squash one persistent failure (running out >> of threads due to sb-ext:run-process not returning), I seem to have >> awoken another. I've got two, possibly unrelated, issues. First, the >> more benign one: >> >> I see the following message quite often in the logs: >> >> [2008-12-23 18:47:38 [ERROR]] Error while processing connection: The >> value 1058 >> is >> not of type >> >> (MOD 1025). >> occasionally the message is: >> >> [2008-12-23 18:46:06 [ERROR]] Error while processing connection: The >> value 1065 >> is >> not of type >> >> (UNSIGNED-BYTE >> >> 10). >> >> any idea where these might be coming from? >> >> The second, more serious, problem is that I seem to end up in ldb >> after a few days of usage: >> >> * Argh! corrupted error depth, halting >> fatal error encountered in SBCL pid 60417(tid 134658560): >> %PRIMITIVE HALT called; the party is over. >> >> Welcome to LDB, a low-level debugger for the Lisp runtime environment. >> ldb> Argh! corrupted error depth, halting >> fatal error encountered in SBCL pid 60417(tid 134659072): >> %PRIMITIVE HALT called; the party is over. >> >> Welcome to LDB, a low-level debugger for the Lisp runtime environment. >> ldb> Argh! corrupted error depth, halting >> fatal error encountered in SBCL pid 60417(tid 136982272): >> %PRIMITIVE HALT called; the party is over. >> >> Welcome to LDB, a low-level debugger for the Lisp runtime environment. >> ldb> > >> >> >> This is a fairly unhelpful error, but I'm wondering if the above- >> mentioned error isn't tickling some bug in the sbcl/freebsd error >> handling code. This ldb droppage is fairly new, AFAICT. There have >> certainly been other failure modes, but this one is new and I'm >> wondering if might be due to recent changes in either SBCL or >> hunchentoot. In any event, I'll try to get some more info from ldb to >> see if I can track this down. >> >> Cyrus >> >> >> _______________________________________________ >> 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 ch-tbnl at bobobeach.com Thu Dec 25 16:48:10 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Thu, 25 Dec 2008 08:48:10 -0800 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: References: <466F62FB-B540-4422-8C44-7869A910EFF7@bobobeach.com> <42CE9B2D-D8B0-4A39-8628-502BFA0FCEE8@bobobeach.com> Message-ID: <995DE0C8-3618-4701-AAE5-B627A067B17C@bobobeach.com> Hi Hans, Far? on #lisp pointed out that sb-ext:run-process has a number of race conditions and goes so far as to suggest that the whole SIGCHLD handling of child processes is pretty fundamentally broken. So, indeed, it does seem that this is the case. The good (?) news is that I can reliably trigger a failure using ab. Sorry to blame hunchentoot. I'll take this up on sbcl-devel. thanks, Cyrus On Dec 25, 2008, at 12:58 AM, Hans Huebner wrote: > Slyrus, > > from looking at the failure description and the stack backtrace, I > would think that the root cause of the problem is in the FreeBSD port > of SBCL, maybe related to signal handling with subprocesses. I know > that this is not a very satisfying response. Maybe you can try to > verify that subprocess handling works properly in a multithreaded > environment by spawning a lot of them from multiple threads, in a > loop, and see if that triggers the same problem. > > -Hans > > On Wed, Dec 24, 2008 at 20:09, Cyrus Harmon > wrote: >> FWIW, >> >> here's a backtrace: >> >> 0: Foreign function ldb_monitor, fp = 0x2ad87f98, ra = 0x8055be3 >> 1: Foreign function lose, fp = 0x2ad87fb8, ra = 0x80534ef >> 2: Foreign function handle_trap, fp = 0x2ad88028, ra = 0x80552c9 >> 3: Foreign fp = 0x2ad8837c, ra = 0xbfbfff94 >> 4: SB-KERNEL::INTERNAL-ERROR >> 5: Foreign function call_into_lisp, fp = 0x2ad88438, ra = 0x806041c >> 6: Foreign function funcall2, fp = 0x2ad88458, ra = 0x805113c >> 7: Foreign function interrupt_internal_error, fp = 0x2ad884a8, ra >> = 0x8053bef >> 8: Foreign function handle_trap, fp = 0x2ad88518, ra = 0x8055201 >> 9: Foreign fp = 0x2ad88868, ra = 0xbfbfff94 >> 10: SB-IMPL::REFILL-INPUT-BUFFER >> 11: SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE >> 12: (SB-C::HAIRY-ARG-PROCESSOR CHUNGA::READ-CHAR*) >> 13: (SB-C::HAIRY-ARG-PROCESSOR CHUNGA::READ-LINE*) >> 14: (SB-C::HAIRY-ARG-PROCESSOR HUNCHENTOOT-CGI::HANDLE-CGI-SCRIPT) >> 15: HUNCHENTOOT::PROCESS-REQUEST >> 16: (SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION (COMMON- >> LISP::T COMMON-LISP::T)) >> 17: (SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION >> KEYWORD::AROUND (COMMON-LISP::T COMMON-LISP::T)) >> 18: (COMMON-LISP::FLET SB-THREAD::WITH-MUTEX-THUNK) >> 19: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477) >> 20: SB-THREAD::CALL-WITH-MUTEX >> 21: (COMMON-LISP::LAMBDA ()) >> 22: Foreign function call_into_lisp, fp = 0x2ad88f58, ra = 0x806041c >> 23: Foreign function funcall0, fp = 0x2ad88f78, ra = 0x80510fe >> 24: Foreign function new_thread_trampoline, fp = 0x2ad88f98, ra = >> 0x8059985 >> 25: Foreign function _pthread_create, fp = 0x2ad88fe8, ra = >> 0x2809d5cf >> >> >> On Dec 24, 2008, at 8:57 AM, Cyrus Harmon wrote: >> >>> so, just when I managed to squash one persistent failure (running >>> out >>> of threads due to sb-ext:run-process not returning), I seem to have >>> awoken another. I've got two, possibly unrelated, issues. First, the >>> more benign one: >>> >>> I see the following message quite often in the logs: >>> >>> [2008-12-23 18:47:38 [ERROR]] Error while processing connection: The >>> value 1058 >>> is >>> not of type >>> >>> (MOD 1025). >>> occasionally the message is: >>> >>> [2008-12-23 18:46:06 [ERROR]] Error while processing connection: The >>> value 1065 >>> is >>> not of type >>> >>> (UNSIGNED-BYTE >>> >>> 10). >>> >>> any idea where these might be coming from? >>> >>> The second, more serious, problem is that I seem to end up in ldb >>> after a few days of usage: >>> >>> * Argh! corrupted error depth, halting >>> fatal error encountered in SBCL pid 60417(tid 134658560): >>> %PRIMITIVE HALT called; the party is over. >>> >>> Welcome to LDB, a low-level debugger for the Lisp runtime >>> environment. >>> ldb> Argh! corrupted error depth, halting >>> fatal error encountered in SBCL pid 60417(tid 134659072): >>> %PRIMITIVE HALT called; the party is over. >>> >>> Welcome to LDB, a low-level debugger for the Lisp runtime >>> environment. >>> ldb> Argh! corrupted error depth, halting >>> fatal error encountered in SBCL pid 60417(tid 136982272): >>> %PRIMITIVE HALT called; the party is over. >>> >>> Welcome to LDB, a low-level debugger for the Lisp runtime >>> environment. >>> ldb> > >>> >>> >>> This is a fairly unhelpful error, but I'm wondering if the above- >>> mentioned error isn't tickling some bug in the sbcl/freebsd error >>> handling code. This ldb droppage is fairly new, AFAICT. There have >>> certainly been other failure modes, but this one is new and I'm >>> wondering if might be due to recent changes in either SBCL or >>> hunchentoot. In any event, I'll try to get some more info from ldb >>> to >>> see if I can track this down. >>> >>> Cyrus >>> >>> >>> _______________________________________________ >>> 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 hans.huebner at gmail.com Tue Dec 30 11:11:46 2008 From: hans.huebner at gmail.com (Hans Huebner) Date: Tue, 30 Dec 2008 12:11:46 +0100 Subject: [hunchentoot-devel] TCP Input timeout on CCL In-Reply-To: References: <47AB15BD-E4F3-42C8-8761-915D7E339B7C@me.com> <1C55A036-9425-4614-8621-F1A7CBFBCDC4@me.com> Message-ID: On Sat, Dec 13, 2008 at 21:26, wrote: >> the development version of Hunchentoot can be obtained by >> >> svn co svn://bknr.net/trunk/ediware This URL is wrong, please use svn://bknr.net/svn/ediware Apologies, Hans From yazicivo at ttmail.com Tue Dec 30 13:58:15 2008 From: yazicivo at ttmail.com (Volkan YAZICI) Date: Tue, 30 Dec 2008 15:58:15 +0200 Subject: [hunchentoot-devel] Limit on Request Content Size Message-ID: <87iqp1n4so.fsf@alamut.mobiliz.com.tr> Hi, [Sorry if this question was raised before, but I couldn't find anything related in the archives.] How can I force a limit on the content size of the request body? Is there such a functionality built into hunchentoot? If not, is GET-POST-DATA the right place to introduce this feature? Regards. From hans.huebner at gmail.com Tue Dec 30 14:53:40 2008 From: hans.huebner at gmail.com (Hans Huebner) Date: Tue, 30 Dec 2008 15:53:40 +0100 Subject: [hunchentoot-devel] Limit on Request Content Size In-Reply-To: <87iqp1n4so.fsf@alamut.mobiliz.com.tr> References: <87iqp1n4so.fsf@alamut.mobiliz.com.tr> Message-ID: On Tue, Dec 30, 2008 at 14:58, Volkan YAZICI wrote: > How can I force a limit on the content size of the request body? Is > there such a functionality built into hunchentoot? If not, is > GET-POST-DATA the right place to introduce this feature? I don't think that Hunchentoot can support a body size limitation in a meaningful way without major refactoring GET-POST-DATA. The WANT-STREAM argument to GET-POST-DATA, chunking and HTTP/0.9 support together make it impossible to enfore the limit in a fashion that would handle all use cases within the existing framework of the GET-POST-DATA function. We are not quite happy with that situation, not only because there is no limit on the incoming request body, but also because of the RFC2388 parser that does not understand encodings. I am not sure whether we'll have the time to fix the problem ourselves soon, so if you can come up with a patch, we might be able to review and incorporate it into the upcoming release. Please make sure that you read http://weitz.de/patches.html before you start. It might be good to discuss the implementation strategy here beforehand. One approach would be to implement the limitation in a gray stream - That way, it may be possible to get away without changing the existing structure too much, but I have not investigated the possibility very deeply. -Hans From enomitch at gmail.com Tue Dec 30 21:02:52 2008 From: enomitch at gmail.com (Erik Nomitch) Date: Tue, 30 Dec 2008 14:02:52 -0700 Subject: [hunchentoot-devel] parameterp? Message-ID: <2e5ff0c80812301302x79360f4av19ff97ddbcac3e9@mail.gmail.com> Hi, I was wondering if there is a better way to test of a get/post parameter is set. In the documentation, it says: *(or NIL if there ain't no parameter with this name)* . But when it's not set and I do (hunchentoot:get-parameter "foo") and it DNE, I get a server error. I'm using Hunchentoot 0.15.7 (SBCL 1.0.22). Here is what I'm currently doing: * (defun parameterp (str) (dolist (x (hunchentoot:get-parameters)) (when (string= (car x) str) (return-from parameterp t))) nil)* Thanks, Erik Nomitch -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomek.lipski at gmail.com Wed Dec 31 08:56:49 2008 From: tomek.lipski at gmail.com (Tomasz Lipski) Date: Wed, 31 Dec 2008 09:56:49 +0100 Subject: [hunchentoot-devel] parameterp? In-Reply-To: <2e5ff0c80812301302x79360f4av19ff97ddbcac3e9@mail.gmail.com> References: <2e5ff0c80812301302x79360f4av19ff97ddbcac3e9@mail.gmail.com> Message-ID: 2008/12/30 Erik Nomitch : > Hi, > > I was wondering if there is a better way to test of a get/post parameter is > set. In the documentation, it says: (or NIL if there ain't no parameter > with this name) . But when it's not set and I do (hunchentoot:get-parameter > "foo") and it DNE, I get a server error. I'm using Hunchentoot 0.15.7 (SBCL > 1.0.22). Here is what I'm currently doing: > > (defun parameterp (str) > (dolist (x (hunchentoot:get-parameters)) > (when (string= (car x) str) > (return-from parameterp t))) > nil) > Hi, can you submit error message and backtrace? >From the top of my head, if the parameter is present in the submitted form and not filled with data it has "" value. When it is not present in the form (get/post-parameter) returns nil (as the documentation says). Simple test proves the point (works in interactive mode): (create-prefix-dispatcher "/" (lambda () (format nil "test=~A" (get-parameter "test")))) (push * *dispatch-table*) (start-server :port 8080) The go to http://localhost:8080/ and http://localhost:8080/?test=1 and http://localhost:8080/?test= Best regards, Tomek Lipski From yazicivo at ttmail.com Wed Dec 31 13:40:18 2008 From: yazicivo at ttmail.com (Volkan YAZICI) Date: Wed, 31 Dec 2008 15:40:18 +0200 Subject: [hunchentoot-devel] Limit on Request Content Size In-Reply-To: (Hans Huebner's message of "Tue\, 30 Dec 2008 15\:53\:40 +0100") References: <87iqp1n4so.fsf@alamut.mobiliz.com.tr> Message-ID: <873ag4pinx.fsf_-_@alamut.mobiliz.com.tr> On Tue, 30 Dec 2008, "Hans Huebner" writes: > I don't think that Hunchentoot can support a body size limitation in a > meaningful way without major refactoring GET-POST-DATA. The > WANT-STREAM argument to GET-POST-DATA, chunking and HTTP/0.9 support > together make it impossible to enfore the limit in a fashion that > would handle all use cases within the existing framework of the > GET-POST-DATA function. > > We are not quite happy with that situation, not only because there is > no limit on the incoming request body, but also because of the RFC2388 > parser that does not understand encodings. I am not sure whether > we'll have the time to fix the problem ourselves soon, so if you can > come up with a patch, we might be able to review and incorporate it > into the upcoming release. > > Please make sure that you read http://weitz.de/patches.html before you > start. It might be good to discuss the implementation strategy here > beforehand. > > One approach would be to implement the limitation in a gray stream - > That way, it may be possible to get away without changing the existing > structure too much, but I have not investigated the possibility very > deeply. Considering your comparison, implementing the limitation in stream structures could be great. In case of a limitation failure, hunchentoot can signal a (restartable) condition. But I don't have an idea about how I could make flexi-streams to force such a limitation while reading streams. Would you mind giving some hints, reading pointers, etc. that I can further study? Regards.