On Mon, 27 Jan 2014 20:03:03 +0100, Sönke Ludwig wrote:
Am 25.01.2014 08:41, schrieb Ty Overby:
Also, why is the form that I was using valid at all? Was it actually doing something that I wasn't detecting?
The problem is that the
serveStaticFiles
function, when it gets a
routed request like "/static/image.png", has no way to know that the
matching route looks like "/static/*" and it should drop the prefix. So
in this case it expects the file to be at "./static/static/image.png".
Did you meant "./public/static/image.png" ?
The example in the documentation assumes that all the static files are
placed directly in "/", so "/image.png" would be looked up in
"./public/image.png" - and for this case it should still be valid.But there should definitely be a short example of using the advanced
settings version ofserveStaticFiles
, if not in the main
documentation, at least on the API page forserveStaticFiles
.
Despite of being an old thread, I have run in the same problem, what about giving the following example:
router.get("/styles/*", serveStaticFiles("public/"));
while addressing the .css directly in diet
link(rel= 'stylesheet', type='text/css', href='/style/style.css`
Or additionaly about extending the allowed expressions with (*) Example:
router.get("/static/(*)", serveStaticFiles("public/"));
`
So that only the matching part (*) of the path is passed to serveStaticFiles?
The use of the other "version" with:auto fsettings = new HTTPFileServerSettings;<br>fsettings.serverPathPrefix = "/static";
is not nice at all.
- point: It seams, that no checking of the existence of path on the file system is done (as string) is done.
Best regards mt.