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 of serveStaticFiles, if not in the main
documentation, at least on the API page for serveStaticFiles.

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.

  1. point: It seams, that no checking of the existence of path on the file system is done (as string) is done.

Best regards mt.