[hunchentoot-devel] handle-static-file

[Frank Schorr]

> -----Ursprüngliche Nachricht-----
> Von: "Hans Hübner" <hans at huebner.org>
> Gesendet: 08.12.08 12:32:13
> An: "General interest list for Hunchentoot and CL-WEBDAV" <tbnl-devel at common-lisp.net>
> Betreff: Re: [hunchentoot-devel] handle-static-file


> On Mon, Dec 8, 2008 at 11:47, Frank Schorr <franks-muc at 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 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