tbnl-devel

tbnl-devel@common-lisp.net

865 discussions

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

[hunchentoot-devel] Logfile question: double entries
by Jens Teich 06 Dec '08

06 Dec '08

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

3 5

[hunchentoot-devel] minor modification to HANDLE-STATIC-FILE
by Vsevolod 05 Dec '08

05 Dec '08

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

3 5

[hunchentoot-devel] Deployment
by Ken Harris 05 Dec '08

05 Dec '08

Hi, all, OK, this maybe isn't 100% Hunchentoot-specific, but it's kind of relevant... I can't find any information about actually deploying a Hunchentoot web app (or any other Lisp server process). So far I've just been running it under SLIME in Emacs on my dev box. With *other platforms* (ugh, I know I'm not supposed to say that), there's often a utility for deploying, or a script you can drop in /etc/init.d, or whatever. I haven't found one for SBCL/Hunchentoot/... yet. How do people typically run these? Just ssh to the server and "sbcl --load myfile.lisp &", where the end of myfile.lisp has a (hunchentoot:start-server ...) call? Something clever with ASDF? (N.b., I barely understand ASDF.) Thanks! - Ken

7 6

[hunchentoot-devel] TCP Input timeout on CCL
by Scott Bell 05 Dec '08

05 Dec '08

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 #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/7) #x30004277FD9D> [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

2 1

[hunchentoot-devel] different sessions in different tabs
by franks-muc＠web.de 02 Dec '08

02 Dec '08

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 _________________________________________________________________________ Sensationsangebot nur bis 30.11: WEB.DE FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K13805B7069a

3 2

[hunchentoot-devel] Hunchentoot Ecl port
by Marko Kocić 26 Nov '08

26 Nov '08

Some time ago someone Geo tried to port hunchentoot to ecl. Since all current hunchentoot dependencies now work with Ecl, his port now works. Here's a slightly modified version of his port attached. Using it I succeded in running hunchentoot test. There are still some problems with utf-8, but tests basically works. Regards, Marko

2 1

[hunchentoot-devel] Help
by Harrison Maseko 21 Nov '08

21 Nov '08

Hi all, I am learning to program and I am currently trying SBCL 1.0.6. via Cusp v0.8.174 on Windows Vista. The first time I started the server on port 4242 to sample the test page everything seemed to work just fine. Any later try to access the test page, however, gives me the following message in both IE7 and Chrome: "Hunchentoot Default Page This the Hunchentoot default page. You're most likely seeing it because the server administrator hasn't set up a custom default page yet. Hunchentoot is a web server written in Common <http://www.lisp.org/> Lisp. More info about Hunchentoot can be found at http://weitz.de/hunchentoot/. _____ Hunchentoot 0.11.1 <http://weitz.de/hunchentoot/> (SBCL 1.0.6) <http://www.sbcl.org/> at localhost:4242" and it ends there. But before trying to access the page, I get the following error messages when loading hunchentoot of which messages I have no idea what they mean: Unable to load foreign library (LIBSSL). Error opening shared object "libssl32.dll": 126. [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR] 0: [RETRY] Try loading the foreign library again. 1: [USE-VALUE] Use another library instead. 2: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "reload" {A70BD89}>. 3: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "reload" {A70BD89}> as having been successful. 4: [ABORT] Return to SLIME's top level. 5: [CLOSE-CONNECTION] Close SLIME connection 6: [ABORT] Exit debugger, returning to top level. ]> 3 Undefined alien: "SSL_get_version" [Condition of type UNDEFINED-ALIEN-ERROR] 0: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "ffi" {A70BDA9}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "ffi" {A70BDA9}> as having been successful. 2: [ABORT] Return to SLIME's top level. 3: [CLOSE-CONNECTION] Close SLIME connection 4: [ABORT] Exit debugger, returning to top level. ]> 1 Undefined alien: "SSL_read" [Condition of type UNDEFINED-ALIEN-ERROR] 0: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "streams" {A70BDD9}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "streams" {A70BDD9}> as having been successful. 2: [ABORT] Return to SLIME's top level. 3: [CLOSE-CONNECTION] Close SLIME connection 4: [ABORT] Exit debugger, returning to top level. Then when I do (asdf:oos 'asdf:load-op :hunchentoot-test) I get the following: ; loading system definition from ; C:\Program Files\eclipse\plugins\jasko.tim.lisp.libs_1.0.0\libs\hunchentoot-0.11.1\hunc hentoot-test.asd ; into #<PACKAGE "ASDF0"> ; registering #<SYSTEM :HUNCHENTOOT-TEST {B6AD791}> as HUNCHENTOOT-TEST error opening #P"C:\\Users\\hmaseko\\Desktop\\eclipse\\plugins\\jasko.tim.lisp.libs_1.0.0\ \libs\\hunchentoot-0.11.1\\test\\fz.jpg": No such file or directory [Condition of type SB-INT:SIMPLE-FILE-ERROR] 0: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {B535AF1}> on #<ASDF:CL-SOURCE-FILE "test" {B6F3DE1}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {B535AF1}> on #<ASDF:CL-SOURCE-FILE "test" {B6F3DE1}> as having been successful. 2: [ABORT] Return to SLIME's top level. 3: [CLOSE-CONNECTION] Close SLIME connection 4: [ABORT] Exit debugger, returning to top level. ]> 1 I am wondering why at some point the path is pointing to my desktop. True, I kept my Eclipse SDK there for a while before moving it to it's permanent location in c:/program files/ but why is the error occuring? There is something I am doing wrong. What is it? Regards, Harrison.

2 3

← Newer
1
...
31
32
33
34
35
36
37
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel