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

[hunchentoot-devel] Limit on Request Content Size
by Volkan YAZICI 05 Jan '09

05 Jan '09

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.

2 3

[hunchentoot-devel] parameterp?
by Erik Nomitch 31 Dec '08

31 Dec '08

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

2 1

Re: [hunchentoot-devel] TCP Input timeout on CCL
by sblist＠me.com 30 Dec '08

30 Dec '08

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

3 3

[hunchentoot-devel] hunchentoot errors
by Cyrus Harmon 25 Dec '08

25 Dec '08

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

2 3

[hunchentoot-devel] long living session
by Jens Teich 17 Dec '08

17 Dec '08

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

3 3

[hunchentoot-devel] only simple-string's are allowed for md5:md5sum-sequence
by Anton Vodonosov 09 Dec '08

09 Dec '08

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

3 2

Re: [hunchentoot-devel] handle-static-file
by Frank Schorr 08 Dec '08

08 Dec '08

> -----Ursprüngliche Nachricht----- > Von: "Hans Hübner" <hans(a)huebner.org> > Gesendet: 08.12.08 14:01:16 > An: "General interest list for Hunchentoot and CL-WEBDAV" <tbnl-devel(a)common-lisp.net> > Betreff: Re: [hunchentoot-devel] handle-static-file > On Mon, Dec 8, 2008 at 13:03, Frank Schorr <franks-muc(a)web.de> 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(a)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

1 0

Re: [hunchentoot-devel] handle-static-file
by Frank Schorr 08 Dec '08

08 Dec '08

> -----Ursprüngliche Nachricht----- > Von: "Hans Hübner" <hans(a)huebner.org> > Gesendet: 08.12.08 12:32:13 > An: "General interest list for Hunchentoot and CL-WEBDAV" <tbnl-devel(a)common-lisp.net> > Betreff: Re: [hunchentoot-devel] handle-static-file > On Mon, Dec 8, 2008 at 11:47, Frank Schorr <franks-muc(a)web.de> 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(a)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

2 1

Re: [hunchentoot-devel] handle-static-file
by Frank Schorr 08 Dec '08

08 Dec '08

> -----Ursprüngliche Nachricht----- > Von: "Hans Hübner" <hans(a)huebner.org> > Gesendet: 08.12.08 11:36:47 > An: "General interest list for Hunchentoot and CL-WEBDAV" <tbnl-devel(a)common-lisp.net> > Betreff: Re: [hunchentoot-devel] handle-static-file > On Mon, Dec 8, 2008 at 10:38, Frank Schorr <franks-muc(a)web.de> 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(a)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

2 1

[hunchentoot-devel] handle-static-file
by Frank Schorr 08 Dec '08

08 Dec '08

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

2 1