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