Cant serve static files

Sat Feb 1 10:58:19 UTC 2014

Ha!
I see, I think I've given up on pathnames once, but now I've got more
time to try to figure them out, so maybe one day I'll have that patch
;)

Thanks for the info, though!

Best,

Oleg

On Sat, Feb 1, 2014 at 12:32 PM, Hans Hübner <hans.huebner at gmail.com> wrote:
> Oleg,
>
> what would be needed is complete support for logical pathnames (which is not
> present at the moment).  I believe that if the document root is a logical
> pathname, the incoming URL would need to be converted to a relative logical
> pathname before it is merged to the document root.
>
> At this point, I am not prepared to work on this myself.  As pathnames are
> hairy business, I would only want to merge a patch to support logical
> pathnames if it comes with thorough tests.
>
> Alternatively, I would accept a documentation patch that says that if the
> document root is a logical pathname, it must not contain a directory or file
> component. :)
>
> -Hans
>
>
> 2014-02-01 Left Right <olegsivokon at gmail.com>:
>
>> Thanks for the answer, Hans,
>>
>> I'm looking now at the misc.lisp,
>> create-folder-dispatcher-and-handler, am I right assuming this is the
>> function that handles paths merging?
>>
>> If so, I was thinking to override request-pathname on request to
>> create a URI with the required bits of the pathname. This would seem
>> to me like a better way to handle it. But I'm not certain what would
>> it mean in terms of other bits of the code, is it likely to break
>> other things?
>>
>> Example:
>>
>> (merge-pathnames (make-pathname :host "rgol" :name "game" :type
>> "html") #p"rgol:www;")
>> #P"RGOL:WWW;GAME.HTML.NEWEST"
>>
>> The reason I want to do it this way is because merge-pathnames will
>> only concatenate paths if the default-pathname is trivial: no
>> directories, wildcards etc. So it seems to me that the original
>> intention was to simply concatenate paths, but because for trivial
>> pathnames merge-pathnames worked as concatenation, it was used. Does
>> it make sense?
>>
>> Best,
>>
>> Oleg
>>
>> On Sat, Feb 1, 2014 at 10:59 AM, Hans Hübner <hans.huebner at gmail.com>
>> wrote:
>> > Oleg,
>> >
>> > the problem seems to be related how logical pathnames are merged.  The
>> > partial pathname that is created by Hunchentoot and then merged with the
>> > document root pathname is considered to contain a directory component by
>> > CL.
>> > Therefore, the directory component that you are matching in your logical
>> > pathname host definition is not present when the two partial pathnames
>> > are
>> > merged.  To work around this behavior, I'd recommend that you define a
>> > separate logical pathname host for your document root.
>> >
>> > TEST-LOGICAL-PATHNAMES> (setf (logical-pathname-translations "TEST")
>> > '(("foo;*.*.*" "/tmp/*")))
>> > (("foo;*.*.*" "/tmp/*"))
>> > TEST-LOGICAL-PATHNAMES> (directory (merge-pathnames "test.txt"
>> > #P"test:foo;"))
>> > NIL
>> > TEST-LOGICAL-PATHNAMES> (setf (logical-pathname-translations "TEST")
>> > '(("*.*.*" "/tmp/*")))
>> > (("*.*.*" "/tmp/*"))
>> > TEST-LOGICAL-PATHNAMES> (directory (merge-pathnames "test.txt"
>> > #P"test:foo;"))
>> > (#P"/private/tmp/test.txt")
>> > TEST-LOGICAL-PATHNAMES> (directory (merge-pathnames "test.txt"
>> > #P"test:"))
>> > (#P"/private/tmp/test.txt")
>> >
>> > -Hans
>> >
>> >
>> > 2014-01-31 Left Right <olegsivokon at gmail.com>:
>> >
>> >> Sorry, I've copied the wrong log entry, this is the correct one:
>> >>
>> >> 127.0.0.1 - [2014-01-31 17:35:44] "GET /game.html HTTP/1.1" 404 188 "-"
>> >> "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
>> >> Chrome/28.0.1500.95 Safari/537.36"
>> >>
>> >>
>> >> On Fri, Jan 31, 2014 at 5:33 PM, Oleg Sivokon <olegsivokon at gmail.com>
>> >> wrote:
>> >>>
>> >>> Hello list,
>> >>>
>> >>> There should be something very simple I've overlooked, yet I can't
>> >>> find
>> >>> it. Hunchentoot seems not to be able to locate the root directory,
>> >>> where
>> >>> I have my static content, and I can't get it to print any useful
>> >>> information about it. That's why I'm asking for your help.
>> >>>
>> >>> Below is my setup:
>> >>>
>> >>> (setf (logical-pathname-translations "rgol")
>> >>>        '(...
>> >>>          ("WWW;*.*.*" "/home/wvxvw/.../www/")
>> >>>          ("WWW;*;*.*.*" "/home/wvxvw/.../www/*")
>> >>>          ...))
>> >>>
>> >>> (make-instance 'hunchentoot:acceptor :port 4242
>> >>>     :document-root #p"rgol:www;"
>> >>>     :message-log-destination #p"rgol:logs;messages.log"
>> >>>     :access-log-destination #p"rgol:logs;access.log")
>> >>>
>> >>> I've defined another handler, which doesn't depend on static files,
>> >>> and
>> >>> it works fine, however, when I try to access static files, the log
>> >>> record looks like this:
>> >>>
>> >>> 127.0.0.1 - [2014-01-31 17:12:40]
>> >>> "GET /img/made-with-lisp-logo.jpg HTTP/1.1"
>> >>> 404 206 "http://localhost:4242/game.html"
>> >>> "Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0"
>> >>>
>> >>> But the file is definitely there, because if I try this in REPL:
>> >>>
>> >>> (directory #p"rgol:www;*.*")
>> >>> (#P"/home/wvxvw/.../www/game.html"
>> >>>  ... more files ...)
>> >>>
>> >>> My version of Hunchentoot is:
>> >>>
>> >>> hunchentoot:*hunchentoot-version*
>> >>> "1.2.17"
>> >>>
>> >>> $ sbcl --version
>> >>> SBCL 1.1.2-1.fc18
>> >>>
>> >>> Best,
>> >>>
>> >>> Oleg
>> >>
>> >>
>> >
>
>