From karilentz at att.net Wed Feb 1 03:17:20 2012 From: karilentz at att.net (Kari Lentz) Date: Tue, 31 Jan 2012 19:17:20 -0800 (PST) Subject: [hunchentoot-devel] Patch Submission: Custom Reason Phrases Message-ID: <1328066240.16436.YahooMailRC@web83804.mail.sp1.yahoo.com> Included is a patch that incorporates the ability to have a request specific reason phrase that allows one to use code such along the lines of (setf (return-code*) (make-custom-status 500 "some database query error"))) This would override the templates and the cooked messages but only for that request and is intended to be an answer to the "StatusDescription" member of the HTTPResponse class in the ASP.NET library. Essentially, a custom-status-t class has been added that links a code with a reason phrase. The "make-custom-status" function above is just a constructor to this new class. The "reason-phrase" function is now a generic method that dispatches off both the custom-status-t class and the previous numeric status codes to be backward compatible. I also ended up changing the error code dispatch to be CLOS based using eql dispatch instead of a case statement for the various http-status-code values. It seems to be a trend to use generic functions instead of a case statement in this situation, probably because of a hash table type dispatch is used behind the scenes rather than going from start to finish as in a case statement. Cheers, Kari -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-hunchen Type: application/octet-stream Size: 13632 bytes Desc: not available URL: From hans.huebner at gmail.com Wed Feb 1 07:28:51 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 1 Feb 2012 08:28:51 +0100 Subject: [hunchentoot-devel] Patch Submission: Custom Reason Phrases In-Reply-To: <1328066240.16436.YahooMailRC@web83804.mail.sp1.yahoo.com> References: <1328066240.16436.YahooMailRC@web83804.mail.sp1.yahoo.com> Message-ID: Hello Kari, thank you for your patch. I have reviewed it, but it is missing documentation. In general, it looks a bit over-engineered at the first sight. Why exactly is a new custom-status-t class needed? What is the use case that it supports? How does a (defmethod hunchentoot:acceptor-status-message ((acceptor my-acceptor) status &key &allow-other-keys) ...) or even several (defmethod hunchentoot:acceptor-status-message ((acceptor my-acceptor) (status (eql +http-bad-request+)) &key &allow-other-keys) ...) not suffice for your application? You can easily cover the ugliness of the specialization syntax with a trivial macro in your application. I'm not sure if the use case needs to be supported by fancier mechanisms in Hunchentoot itself, but maybe some other user here wants to speak up and support the case? Please explain your design motivation and rationale a bit more so that we can understand why the added complexity is worthwhile. Some source-level notes: - Avoid abbreviations: define-make-... instead of def-make-... - An opening parenthesis is always preceded by whitespace - An opening parenthesis is never followed by whitespace - Docstrings are wrapped at 80 characters or less - Don't refer to other frameworks when explaining our features in documentation - Don't use ad-hoc reverse hungarian notation (custom-status-T) - Use generalized booleans unless there is a reason not to (when (>= status 400) t)) - Don't use PROGN without a reason - Long lines are not forbidden, but neither are shorter ones if it makes code easier to read Sorry to have to reject your patch as it stands, Hans On Wed, Feb 1, 2012 at 4:17 AM, Kari Lentz wrote: > Included is a patch that incorporates the ability to have a request specific > reason phrase that allows one to use code such along the lines of > > ?(setf (return-code*) (make-custom-status 500 "some database query error"))) > > This would override the templates and the cooked messages but only for that > request and is intended to be an answer to the "StatusDescription" member of > the HTTPResponse class in the ASP.NET library.? Essentially, a > custom-status-t class has been added that links a code with a reason > phrase.? The "make-custom-status" function above is just a constructor to > this new class. The "reason-phrase" function is now a generic method that > dispatches off both the custom-status-t class and the previous numeric > status codes to be backward compatible. > > I also ended up changing the error code dispatch to be CLOS based using eql > dispatch instead of a case statement for the various http-status-code > values.? It seems to be a trend to use generic functions instead of a case > statement in this situation, probably because of a hash table type dispatch > is used behind the scenes rather than going from start to finish as in a > case statement. > > Cheers, > > Kari > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From stoye at stoye.com Wed Feb 1 19:23:13 2012 From: stoye at stoye.com (Ralf Stoye) Date: Wed, 1 Feb 2012 20:23:13 +0100 Subject: [hunchentoot-devel] hunchentoot cookie-values - url-encode them or not Message-ID: <54424633-FAA6-4F16-99C0-B249787F3B68@stoye.com> As you can see on git, future hunchentoot versions will not url-encode/decode cookie-values anymore. Since this encoding is an de facto standard regarding php, java and perl, and it might break existing code, i would like to hear your opinion about that. At a minimum i want to suggest to introduce a sanity-check on #'cookie-values throwing an error if someone tries to set the value to a nonconforming value (similar to the check on valid cookie-names). The following code is an example predicate: (defun http-cookie-value-p (value) "Tests whether VALUE is a string which is a valid cookie-value according to RFC 6265" (and (stringp value) (not (some (lambda (char) (let ((cc (char-code char))) (or (< cc #x21) (= #x22 cc) (= #x2c cc) (= #x3b cc) (= #x5c cc) (> cc #x7e)))) value)))) the decision is a matter of performance versus simplicity: we could decide to always encode cookie values (eg. per base64 or url-encode, or both) or leave the decision and responsability to the application. Regards, Ralf Stoye From stoye at stoye.com Wed Feb 1 19:47:39 2012 From: stoye at stoye.com (Ralf Stoye) Date: Wed, 1 Feb 2012 20:47:39 +0100 Subject: [hunchentoot-devel] Patch Submission: Custom Reason Phrases In-Reply-To: References: <1328066240.16436.YahooMailRC@web83804.mail.sp1.yahoo.com> Message-ID: Hi, sorry, but i have to agree with Hans. KISS, Keep it small and simple: The change adds complexity for a nonexisting or rather uncommon task. Most applications have to deal with errors themselves, so they implement own strategies for this cases. And as Hans pointed out, there are already hooks (methods) to customize the behaviour of hunchentoot. Regarding coding standards & naming-conventions i have nothing to add to hans' reply. Greetings from Bonn, Germany Ralf Stoye From hans.huebner at gmail.com Wed Feb 1 20:00:03 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 1 Feb 2012 21:00:03 +0100 Subject: [hunchentoot-devel] hunchentoot cookie-values - url-encode them or not In-Reply-To: <54424633-FAA6-4F16-99C0-B249787F3B68@stoye.com> References: <54424633-FAA6-4F16-99C0-B249787F3B68@stoye.com> Message-ID: Ralf, all, I have made the change that Ralf pointed out because I had to read a cookie value that was set by a Rails application and that was not URL-encoded. Thus, I'd question the claim that URL-encoding cookies is a "de facto standard". The HTTP standard does not mandate any standard encoding for cookies, but only restricts their character set. I am open to a check similar to one that Ralf proposed, although I would have Hunchentoot generate an error when the application tries to set a cookie that contains invalid characters. -Hans On Wed, Feb 1, 2012 at 8:23 PM, Ralf Stoye wrote: > As you can see on git, future hunchentoot versions will not url-encode/decode cookie-values anymore. > Since this encoding is an de facto standard regarding php, java and perl, > and it might break existing code, i would like to hear your opinion about that. > > At a minimum i want to suggest to introduce a sanity-check on #'cookie-values > throwing an error if someone tries to set the value to a nonconforming value > (similar to the check on valid cookie-names). > The following code is an example predicate: > > (defun http-cookie-value-p (value) > ?"Tests whether VALUE is a string which is a valid cookie-value according to RFC 6265" > ?(and (stringp value) > ? ? ? (not (some (lambda (char) > ? ? ? ? ? ? ? (let ((cc (char-code char))) > ? ? ? ? ? ? ? ? (or (< cc #x21) > ? ? ? ? ? ? ? ? ? ? ?(= #x22 cc) > ? ? ? ? ? ? ? ? ? ? ?(= #x2c cc) > ? ? ? ? ? ? ? ? ? ? ?(= #x3b cc) > ? ? ? ? ? ? ? ? ? ? ?(= #x5c cc) > ? ? ? ? ? ? ? ? ? ? ?(> cc #x7e)))) > ? ? ? ? ? ? ? ? ?value)))) > > the decision is a matter of performance versus simplicity: > we could decide to always encode cookie values (eg. per base64 or url-encode, or both) > or leave the decision and responsability to the application. > > Regards, > Ralf Stoye > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From stoye at stoye.com Thu Feb 2 14:13:15 2012 From: stoye at stoye.com (Ralf Stoye) Date: Thu, 2 Feb 2012 15:13:15 +0100 Subject: [hunchentoot-devel] hunchentoot cookie-values - url-encode them or not In-Reply-To: References: <54424633-FAA6-4F16-99C0-B249787F3B68@stoye.com> Message-ID: <077B1E5C-E045-4AE0-976C-A0DA5CD5C77C@stoye.com> Hi, let me correct my last post: 1. The standard is RFC 6265, but many people are used to url-encode. url-encoding is the common answer on lists & discussion-groups. 2. I didn't expressed clearly that i also want Hunchentoot to validate AND throwing an error when validation fails. 3. The given http-cookie-value-p is wrong. (doesn't honor the fact that it is allowed to wrap the Token in Doubleqoutes (#x22). 4. your example shows that the decision is not a matter of performance versus simplicity, it's about correctness. So i vote for a correct implementation, validating the value and throwing an appropriate error. Ralf From hans.huebner at gmail.com Thu Feb 2 14:23:47 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 2 Feb 2012 15:23:47 +0100 Subject: [hunchentoot-devel] hunchentoot cookie-values - url-encode them or not In-Reply-To: <077B1E5C-E045-4AE0-976C-A0DA5CD5C77C@stoye.com> References: <54424633-FAA6-4F16-99C0-B249787F3B68@stoye.com> <077B1E5C-E045-4AE0-976C-A0DA5CD5C77C@stoye.com> Message-ID: On Thu, Feb 2, 2012 at 3:13 PM, Ralf Stoye wrote: > 1. The standard is RFC 6265, but many people are used to url-encode. url-encoding is the common answer on lists & discussion-groups. > 2. I didn't expressed clearly that i also want Hunchentoot to validate AND throwing an error when validation fails. > 3. The given http-cookie-value-p is wrong. (doesn't honor the fact that it is allowed to wrap the Token in Doubleqoutes (#x22). > 4. your example shows that the decision is not a matter of performance versus simplicity, it's about correctness. > > So i vote for a correct implementation, validating the value and throwing an appropriate error. I'll gladly merge a pull request with a patch that validates cookie values set by the application! -Hans From fbogdanovic at xnet.hr Sun Feb 5 19:56:17 2012 From: fbogdanovic at xnet.hr (Haris Bogdanovich) Date: Sun, 5 Feb 2012 20:56:17 +0100 Subject: [hunchentoot-devel] installing Message-ID: <2E3FD744B455442A9AE354EFC6AAD878@komp> Hi. I loaded the file .lispworks (also by Edi Weitz) so that Lispworks behaves like Emacs. Hunchentoot folder is in asdf:*central-registry* with all dependencies. When I try (load-system 'hunchentoot) I get: Error: System HUNCHENTOOT not found. cl-who is also in *central-registry* and when I try to load it with: (load-system 'cl-who) it goes without a problem. Where is the problem with Hunchentoot ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From fahree at gmail.com Sun Feb 5 20:47:05 2012 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Sun, 5 Feb 2012 15:47:05 -0500 Subject: [hunchentoot-devel] installing In-Reply-To: <2E3FD744B455442A9AE354EFC6AAD878@komp> References: <2E3FD744B455442A9AE354EFC6AAD878@komp> Message-ID: On Sun, Feb 5, 2012 at 14:56, Haris Bogdanovich wrote: > Hi. > > I loaded the file .lispworks (also by Edi Weitz) > so that Lispworks behaves like Emacs. > Hunchentoot folder is in asdf:*central-registry* with all > dependencies. When I try (load-system 'hunchentoot) I get: > Error: System HUNCHENTOOT not found. > cl-who is also in *central-registry* and when I try to load it with: > (load-system 'cl-who) it goes without a problem. > Where is the problem with Hunchentoot ? > Did you remember to include the trailing / in the paths you pushed to the central-registry? If you did, can you show us the value of asdf:*central-registry* ? Which version of asdf are you using? (asdf:asdf-version) ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org If you think health care is expensive now, wait until you see what it costs when it's free. ? P.J. O'Rourke From fbogdanovic at xnet.hr Mon Feb 6 12:10:30 2012 From: fbogdanovic at xnet.hr (Haris Bogdanovich) Date: Mon, 6 Feb 2012 13:10:30 +0100 Subject: [hunchentoot-devel] installing References: <2E3FD744B455442A9AE354EFC6AAD878@komp> Message-ID: <0D9B2789795E421DB4CE253501075885@komp> > Did you remember to include the trailing / in the paths you pushed to > the central-registry? > > If you did, can you show us the value of asdf:*central-registry* ? > Which version of asdf are you using? (asdf:asdf-version) The version of asdf is 2.019 and my *central-registry* is: (#P"c:/home/lisp/chunga-1.1.1/" #P"c:/home/lisp/cl-base64-3.3.3/" #P"c:/home/lisp/cl-fad-0.6.3/" #P"c:/home/lisp/cl-ppcre-2.0.3/" #P"c:/home/lisp/cl-who-0.11.1/" #P"c:/home/lisp/drakma-1.2.3/" #P"c:/home/lisp/flexi-streams-1.0.7/" #P"c:/home/lisp/hunchentoot-1.1.1/" #P"c:/home/lisp/lw-add-ons-0.8.9/" #P"c:/home/lisp/lw-doc-0.3.3/" #P"c:/home/lisp/md5-1.8.5/" #P"c:/home/lisp/rfc2388/" #P"c:/home/lisp/trivial-backtrace/") From fbogdanovic at xnet.hr Wed Feb 8 13:49:34 2012 From: fbogdanovic at xnet.hr (Haris Bogdanovich) Date: Wed, 8 Feb 2012 14:49:34 +0100 Subject: [hunchentoot-devel] starting Message-ID: Hi. I did this: (push (create-prefix-dispatcher "/index" 'index) *dispatch-table*) (start (make-instance 'acceptor)) and then I go to: http://localhost/index it always goes to Hunchentoot default page ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicdevel at gmail.com Wed Feb 8 14:57:55 2012 From: nicdevel at gmail.com (Nic M) Date: Wed, 8 Feb 2012 09:57:55 -0500 Subject: [hunchentoot-devel] starting In-Reply-To: References: Message-ID: I think you want: (push (create-prefix-dispatcher "/index" 'index) *dispatch-table*) (start (make-instance 'easy-acceptor)) Nic On Wed, Feb 8, 2012 at 8:49 AM, Haris Bogdanovich wrote: > ** > Hi. > > I did this: > > (push (create-prefix-dispatcher "/index" 'index) *dispatch-table*) > (start (make-instance 'acceptor)) > > and then I go to: > > http://localhost/index > > it always goes to Hunchentoot default page ? > > Thanks > > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at dbrunner.de Wed Feb 8 15:28:14 2012 From: daniel at dbrunner.de (Daniel Brunner) Date: Wed, 08 Feb 2012 16:28:14 +0100 Subject: [hunchentoot-devel] starting In-Reply-To: References: Message-ID: <4F32948E.3070503@dbrunner.de> Hi Haris, you should go for the easy-acceptor as written in the documentation. The behaviour of the acceptor changed. http://weitz.de/hunchentoot/#start Kind regards, Daniel. Am 08.02.2012 14:49, schrieb Haris Bogdanovich: > Hi. > > I did this: > > (push (create-prefix-dispatcher "/index" 'index) *dispatch-table*) > (start (make-instance 'acceptor)) > > and then I go to: > > http://localhost/index > > it always goes to Hunchentoot default page ? > > Thanks > > > > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From jingtaozf at gmail.com Thu Feb 9 13:21:13 2012 From: jingtaozf at gmail.com (Xu Jingtao) Date: Thu, 09 Feb 2012 21:21:13 +0800 (CST) Subject: [hunchentoot-devel] why symbol 'acceptor-remove-session' is not exported in hunchentoot 1.2.2? Message-ID: <20120209.212113.391280476922157496.jingtaozf@gmail.com> I have todefine 'acceptor-remove-session' method in my acceptor,but It is not exported in hunchentoot 1.2.2. I wonder why not export it? With best regards. ___________________________________ Jingtao Xu A Lisp Programmer www.jingtao.net From hans.huebner at gmail.com Thu Feb 9 13:34:35 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 9 Feb 2012 14:34:35 +0100 Subject: [hunchentoot-devel] why symbol 'acceptor-remove-session' is not exported in hunchentoot 1.2.2? In-Reply-To: <20120209.212113.391280476922157496.jingtaozf@gmail.com> References: <20120209.212113.391280476922157496.jingtaozf@gmail.com> Message-ID: On Thu, Feb 9, 2012 at 2:21 PM, Xu Jingtao wrote: > > I have todefine 'acceptor-remove-session' method in my acceptor,but It is not > exported in hunchentoot 1.2.2. > > I wonder why not export it? It is exported in the latest development version (https://github.com/edicl/hunchentoot/commit/9fcd0433b9e7e23525b8c868dfc0f20f44c24970). I'm going to make a release soon. Thanks, Hans > > With best regards. > ___________________________________ > Jingtao Xu > A Lisp Programmer > www.jingtao.net > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From jingtaozf at gmail.com Thu Feb 9 14:10:15 2012 From: jingtaozf at gmail.com (Xu Jingtao) Date: Thu, 09 Feb 2012 22:10:15 +0800 (CST) Subject: [hunchentoot-devel] why symbol 'acceptor-remove-session' is not exported in hunchentoot 1.2.2? In-Reply-To: References: <20120209.212113.391280476922157496.jingtaozf@gmail.com> Message-ID: <20120209.221015.258918009869544244.jingtaozf@gmail.com> Thanks for your reply. Best Regards. jingtao. > On Thu, Feb 9, 2012 at 2:21 PM, Xu Jingtao wrote: > > > > I have todefine 'acceptor-remove-session' method in my acceptor,but It is not > > exported in hunchentoot 1.2.2. > > > > I wonder why not export it? > > It is exported in the latest development version > (https://github.com/edicl/hunchentoot/commit/9fcd0433b9e7e23525b8c868dfc0f20f44c24970). > I'm going to make a release soon. > > Thanks, > Hans > > > > > With best regards. > > ___________________________________ > > Jingtao Xu > > A Lisp Programmer > > www.jingtao.net > > > > _______________________________________________ > > 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 fbogdanovic at xnet.hr Thu Feb 9 19:48:04 2012 From: fbogdanovic at xnet.hr (Haris Bogdanovich) Date: Thu, 9 Feb 2012 20:48:04 +0100 Subject: [hunchentoot-devel] starting References: Message-ID: <21646B0FDCBB40EA94A871F5D1448D03@komp> I think you want: (push (create-prefix-dispatcher "/index" 'index) *dispatch-table*) (start (make-instance 'easy-acceptor)) I tried that but I get error that easy-acceptor is not name of a class ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at dbrunner.de Thu Feb 9 20:43:55 2012 From: daniel at dbrunner.de (Daniel Brunner) Date: Thu, 09 Feb 2012 21:43:55 +0100 Subject: [hunchentoot-devel] starting In-Reply-To: <21646B0FDCBB40EA94A871F5D1448D03@komp> References: <21646B0FDCBB40EA94A871F5D1448D03@komp> Message-ID: <4F34300B.6070205@dbrunner.de> That sounds strange. What does > (require 'hunchentoot) > (find-class 'hunchentoot:easy-acceptor) give? Perhaps you forgot to put a (use-package :hunchentoot) in your code? Kind regards, Daniel Am 09.02.2012 20:48, schrieb Haris Bogdanovich: > I think you want: > > (push (create-prefix-dispatcher "/index" 'index) *dispatch-table*) > (start (make-instance 'easy-acceptor)) > > I tried that but I get error that easy-acceptor is not name of a class ? > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From fbogdanovic at xnet.hr Fri Feb 10 13:07:42 2012 From: fbogdanovic at xnet.hr (Haris Bogdanovich) Date: Fri, 10 Feb 2012 14:07:42 +0100 Subject: [hunchentoot-devel] starting References: <21646B0FDCBB40EA94A871F5D1448D03@komp> <4F34300B.6070205@dbrunner.de> Message-ID: <08AF38D5E072463E8B511FC86376886C@komp> > That sounds strange. > > What does > >> (require 'hunchentoot) >> (find-class 'hunchentoot:easy-acceptor) Find class returns the same message that there is not such class. I installed Hunchetntoot with the latest asdf and also with Quicklisp but nothing. Indeed this is a bit strange. I have this at the beginning of the file: (defpackage x (:use :cl :hunchentoot :cl-who)) (in-package x) I'll try the same thing in Lispworks in Linux. From patrick.may at mac.com Sun Feb 12 20:02:59 2012 From: patrick.may at mac.com (Patrick May) Date: Sun, 12 Feb 2012 15:02:59 -0500 Subject: [hunchentoot-devel] Ediware packages missing from Git In-Reply-To: References: <6578E0D6-EF87-4178-BF04-D1F2FE988086@mac.com> Message-ID: <26F15C24-C5D2-421C-942C-1496F36752DC@mac.com> Hans, Thanks for the recommendation. After trying out quicklisp, I've changed our development process to use it in all environments. It makes production updates much simpler. Regards, Patrick On Jan 3, 2012, at 2:04 AM, Hans H?bner wrote: > Hi Patrick, > > On Mon, Jan 2, 2012 at 11:42 PM, Patrick May wrote: >> Are there any plans to add puri (used by drakma) and trivial-gray-streams (used by chunga and flexi-streams) to the git repository so that all required packages are available in one spot? (Yes, I know that cxml and uffi, used by cl-webdav and cl-gd respectively, are also not in Git, but I'm primarily using Hunchentoot, cl-who, and Drakma.) > > I have no plans to include third-party libraries in the edicl > repository - I am using quicklisp to install dependencies and > recommend that as the preferred method for users. > > Best regards, > Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From jingtaozf at gmail.com Mon Feb 13 21:56:26 2012 From: jingtaozf at gmail.com (support@ixiaozhushou.com) Date: Tue, 14 Feb 2012 05:56:26 +0800 (CST) Subject: [hunchentoot-devel] session is timed out in IE browser sometimes. Message-ID: <4f3987cf.d638e70a.0e0f.065e@mx.google.com> Hi all, This may be not a hunchentoot problem but I am not sure. I use hunchentoot 1.1.1 as my web server proxy which location is Japan and browse it with IE in China. I am sure the client and the server's time is the same. But the session is timed out in IE browser sometimes. This question never happened in chrome browser. Is this a question of hunchentoot or someone else have met this question before? With Best Regards. ___________________________________ Jingtao Xu A Lisp Programmer www.jingtao.net From jingtaozf at gmail.com Wed Feb 29 01:55:36 2012 From: jingtaozf at gmail.com (Xu Jingtao) Date: Wed, 29 Feb 2012 09:55:36 +0800 (CST) Subject: [hunchentoot-devel] hunchentoot-1.2.2 throw a Recursive lock attempt error in sbcl 1.0.55 Message-ID: <20120229.095536.2234962845662686644.jingtaozf@gmail.com> Hi all, I update my hunchentoot from 1.1.1 to 1.2.2 a few days ago,and create an accepter like this: ============================================================================ (make-instance 'acceptor :address "127.0.0.1" :port port :access-log-destination (strcat *log-path* "access.log") :message-log-destination (strcat *log-path* "message.log")) ============================================================================ A few hours later,hunchentoot will throw an error message like this: ============================================================================ debugger invoked on a SIMPLE-ERROR in thread #: Recursive lock attempt #S(SB-THREAD:MUTEX :NAME "global-message-log-lock" :%OWNER # :STATE 1). ============================================================================ And the site will not hand request any more. stop server seems dead too. I have to roll back to 1.1.1 at this time. With Best Regards. ___________________________________ Jingtao Xu www.jingtao.net From z_axis at 163.com Wed Feb 29 02:01:50 2012 From: z_axis at 163.com (z_axis) Date: Wed, 29 Feb 2012 10:01:50 +0800 Subject: [hunchentoot-devel] hunchentoot-1.2.2 throw a Recursive lock attempt error in sbcl 1.0.55 In-Reply-To: <20120229.095536.2234962845662686644.jingtaozf@gmail.com> References: <20120229.095536.2234962845662686644.jingtaozf@gmail.com> Message-ID: How about using easy-acceptor instead of acceptor ? ? Wed, 29 Feb 2012 09:55:36 +0800?Xu Jingtao ??: > Hi all, > > I update my hunchentoot from 1.1.1 to 1.2.2 a few days ago,and create an > accepter like this: > ============================================================================ > (make-instance 'acceptor :address "127.0.0.1" :port port > :access-log-destination (strcat *log-path* "access.log") > :message-log-destination (strcat *log-path* "message.log")) > ============================================================================ > > A few hours later,hunchentoot will throw an error message like this: > ============================================================================ > debugger invoked on a SIMPLE-ERROR in thread # "hunchentoot-worker-127.0.0.1:43115" > RUNNING > {C4F7F19}>: > Recursive lock attempt #S(SB-THREAD:MUTEX > :NAME "global-message-log-lock" > :%OWNER # "hunchentoot-worker-127.0.0.1:43115" > RUNNING > {C4F7F19}> > :STATE 1). > ============================================================================ > And the site will not hand request any more. > > stop server seems dead too. > > I have to roll back to 1.1.1 at this time. > > With Best Regards. > ___________________________________ > Jingtao Xu > www.jingtao.net > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -- ?? Opera ????????????: http://www.opera.com/mail/ From jingtaozf at gmail.com Wed Feb 29 02:12:04 2012 From: jingtaozf at gmail.com (Xu Jingtao) Date: Wed, 29 Feb 2012 10:12:04 +0800 (CST) Subject: [hunchentoot-devel] hunchentoot-1.2.2 throw a Recursive lock attempt error in sbcl 1.0.55 In-Reply-To: References: <20120229.095536.2234962845662686644.jingtaozf@gmail.com> Message-ID: <20120229.101204.1977165022081142507.jingtaozf@gmail.com> Sorry,I use easy-acceptor indeed. the code below should be easy-acceptor. > How about using easy-acceptor instead of acceptor ? > > ? Wed, 29 Feb 2012 09:55:36 +0800?Xu Jingtao ??: > > > Hi all, > > > > I update my hunchentoot from 1.1.1 to 1.2.2 a few days ago,and create an accepter like > > this: > > ============================================================================ > > (make-instance 'acceptor :address "127.0.0.1" :port port > > :access-log-destination (strcat *log-path* "access.log") > > :message-log-destination (strcat *log-path* "message.log")) > > ============================================================================ > > > > A few hours later,hunchentoot will throw an error message like this: > > ============================================================================ > > debugger invoked on a SIMPLE-ERROR in thread # > "hunchentoot-worker-127.0.0.1:43115" RUNNING > > {C4F7F19}>: > > Recursive lock attempt #S(SB-THREAD:MUTEX > > :NAME "global-message-log-lock" > > :%OWNER # > "hunchentoot-worker-127.0.0.1:43115" RUNNING > > {C4F7F19}> > > :STATE 1). > > ============================================================================ > > And the site will not hand request any more. > > > > stop server seems dead too. > > > > I have to roll back to 1.1.1 at this time. > > > > With Best Regards. > > ___________________________________ > > Jingtao Xu > > www.jingtao.net > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > -- > ?? Opera ????????????: http://www.opera.com/mail/ > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans.huebner at gmail.com Wed Feb 29 20:38:42 2012 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 29 Feb 2012 15:38:42 -0500 Subject: [hunchentoot-devel] hunchentoot-1.2.2 throw a Recursive lock attempt error in sbcl 1.0.55 In-Reply-To: <20120229.095536.2234962845662686644.jingtaozf@gmail.com> References: <20120229.095536.2234962845662686644.jingtaozf@gmail.com> Message-ID: On Tue, Feb 28, 2012 at 8:55 PM, Xu Jingtao wrote: > I update my hunchentoot from 1.1.1 to 1.2.2 a few days ago,and create an accepter like this: [...] > A few hours later,hunchentoot will throw an error message like this: > debugger invoked on a SIMPLE-ERROR in thread # ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "hunchentoot-worker-127.0.0.1:43115" RUNNING > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {C4F7F19}>: > ?Recursive lock attempt #S(SB-THREAD:MUTEX > ? ? ? ? ? ? ? ? ? ? ? ? ? ?:NAME "global-message-log-lock" > ? ? ? ? ? ? ? ? ? ? ? ? ? ?:%OWNER # ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"hunchentoot-worker-127.0.0.1:43115" RUNNING > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{C4F7F19}> > ? ? ? ? ? ? ? ? ? ? ? ? ? ?:STATE 1). I have not been able to reproduce this problem. Can you provide a way to reproduce it? Thanks, -Hans