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@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@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@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
>>
>>
>