Currently, if you use create-folder-dispatcher-and-handler to create a handler, it will call handle-static-file on a URL like http://bogushost.tld/this/is/a/directory and will give the contents of the directory as returned by fopen'ing the directory, which probably isn't what we want. The following patch to handle-static-file makes sure that the truename of the file has either a pathname-name or a pathname-type.
Not sure if this is desired behavior or not, but I'd rather see a 500 error here. There's another error where if one sets up a folder- dispatcher-and-handler to catch "/www/foo/" and you request "/www/ foo/" you git an internal server error instead of a 500 error, but I haven't worked out the patch for that one yet.
Thanks,
Cyrus
--- misc.lisp Thu Feb 7 18:46:24 2008 +++ misc-patched.lisp Thu Feb 7 18:46:01 2008 @@ -137,11 +137,12 @@ 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 (or (pathname-name path) - (pathname-type path)) - ;; not a file - (setf (return-code) +http-bad-request+) - (throw 'handler-done nil)) + (let ((true-path (truename path))) + (unless (or (pathname-name true-path) + (pathname-type true-path)) + ;; not a file + (setf (return-code) +http-bad-request+) + (throw 'handler-done nil))) (unless (probe-file path) ;; does not exist (setf (return-code) +http-not-found+)
On Thu, 7 Feb 2008 17:36:40 -0800, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
Currently, if you use create-folder-dispatcher-and-handler to create a handler, it will call handle-static-file on a URL like http://bogushost.tld/this/is/a/directory and will give the contents of the directory as returned by fopen'ing the directory, which probably isn't what we want. The following patch to handle-static-file makes sure that the truename of the file has either a pathname-name or a pathname-type.
On which Lisp does that solve the problem?
CLISP on Windows:
CL-USER> (pathname-name (truename "c:\WINDOWS")) "WINDOWS"
AllegroCL on Linux:
CL-USER(1): (pathname-name (truename "/tmp")) "tmp"
(Yes, these are both directories.)
I fear we're in unknown territory and need to resort to something like CL-FAD for a real solution... :(
Not sure if this is desired behavior or not, but I'd rather see a 500 error here. There's another error where if one sets up a folder- dispatcher-and-handler to catch "/www/foo/" and you request "/www/ foo/" you git an internal server error instead of a 500 error, but I haven't worked out the patch for that one yet.
Hmm, sounds vaguely familiar. Didn't we have something like this already?
Thanks, Edi.
On Feb 8, 2008, at 6:19 AM, Edi Weitz wrote:
On which Lisp does that solve the problem?
CLISP on Windows:
CL-USER> (pathname-name (truename "c:\WINDOWS")) "WINDOWS"
AllegroCL on Linux:
CL-USER(1): (pathname-name (truename "/tmp")) "tmp"
(Yes, these are both directories.)
I fear we're in unknown territory and need to resort to something like CL-FAD for a real solution... :(
Darn. On SBCL on Mac OS (and presumably linux, etc...) I get:
CL-USER> (pathname-name (truename "/tmp")) NIL
The joy of CL pathnames... Yes, cl-fad seems like a reasonable approach to me.
Not sure if this is desired behavior or not, but I'd rather see a 500 error here. There's another error where if one sets up a folder- dispatcher-and-handler to catch "/www/foo/" and you request "/www/ foo/" you git an internal server error instead of a 500 error, but I haven't worked out the patch for that one yet.
Hmm, sounds vaguely familiar. Didn't we have something like this already?
If we did it doesn't seem to be in 0.15.0.
Thanks,
Cyrus
Cyrus Harmon ch-tbnl@bobobeach.com writes:
On Feb 8, 2008, at 6:19 AM, Edi Weitz wrote:
On which Lisp does that solve the problem?
CLISP on Windows:
CL-USER> (pathname-name (truename "c:\WINDOWS")) "WINDOWS"
AllegroCL on Linux:
CL-USER(1): (pathname-name (truename "/tmp")) "tmp"
(Yes, these are both directories.)
I fear we're in unknown territory and need to resort to something like CL-FAD for a real solution... :(
Darn. On SBCL on Mac OS (and presumably linux, etc...) I get:
CL-USER> (pathname-name (truename "/tmp")) NIL
Just for the record:
SBCL 1.0.14.10 on x86-64 linux:
CL-USER> (pathname-name (truename "/tmp")) NIL
CLISP 2.41 on x86-64 linux:
[1]> (truename "/tmp")
*** - TRUENAME: "/tmp" names a directory, not a file The following restarts are available: ABORT :R1 ABORT Break 1 [2]>
[16]> (truename "/tmp/") #P"/tmp/" [18]> (pathname-name (truename "/tmp/")) NIL
On Fri, 8 Feb 2008 08:34:41 -0800, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
Hmm, sounds vaguely familiar. Didn't we have something like this already?
If we did it doesn't seem to be in 0.15.0.
No, I meant we had this problem before. See the December 2007 archives of the mailing list.
Yes, that should be fixed as well.
On Fri, 8 Feb 2008 08:34:41 -0800, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
Yes, cl-fad seems like a reasonable approach to me.
See the latest release. Should also hopefully fix the other problem you reported.
I've chosen to always reply "Not Found" now as I think we don't have to give the bad guys hints about our directory structure by sometimes (in the case of folders) saying "Bad Request".
Edi.