fileserver: Fix try_files for directories, windows fix

[francislavoie]

Discussion: https://caddy.community/t/file-not-file-testing-question/9564

The gist of it is that the trailing / was being stripped by path.Clean, so the condition in strictFileExists expecting a trailing / indicating a directory expected wasn't working because it would never have a / once it got there.

But on top of this, sanitizedPathJoin had this issue as well, because filepath.Join also cleans the path. I updated that code to re-add the path separator as well.

I refactored the common lines between all the try policies that set up suffix and fullpath into a closure for obvious reasons.

And finally, strictFileExists was checking specifically for a trailing / which did not work on Windows, so I changed that to use the filepath.Separator constant to work on Windows (I wrote and tested these changes on Windows).

Note that sanitizedPathJoin is used in file_server browse but path.Join is called before on the path, so no trailing slash should exist, so the behaviour should stay the same for that code path.

[francislavoie]

FYI @mholt I added a new feature in the second commit in here (because it doesn't super make sense to be in a new PR since it sorta depends on these changes).

I added a new placeholder {http.matchers.file.type} which can be set to either file or directory based on what's matched. That can be useful for chaining into another matcher (i.e. expression matcher) which can do things based on whether a file or directory was matched.

Also did some refactoring to make this a bit simpler, and to centralize the placeholder setup in the file matcher. It could be simplified further probably, and you'll probably tell me to move the closure out... but 🤷‍♂️ this is what I felt like doing for now! I can clean it up further if you think this is ok.

I can drop that 2nd commit if you don't want it, but I think it's useful.

Some discussion here: https://caddy.community/t/how-to-determine-if-a-path-is-a-directory-or-a-file/9643/2

Also I kinda think this should go in 2.2, since it's a pretty good bug fix.

[mholt]

Thanks, will look at this closer soon. Working though my backlog. 😃

I added a new placeholder {http.matchers.file.type} which can be set to either file or directory based on what's matched. That can be useful for chaining into another matcher (i.e. expression matcher) which can do things based on whether a file or directory was matched.

If I recall correctly, file matchers are designed to match either a directory or a file based solely on whether a separator (I used / but I guess on windows we need \ as you noted) suffixed the path: if so, match only directories; if not, match only files. How useful is the placeholder if there is no variance in the file matching?

[francislavoie]

This PR specifically fixes file matching so that if you use {path}/, it will match a directory. It wouldn't at all before. So because of that, that placeholder becomes useful.

[mholt]

Okay, cool. But {path}/ would never match anything other than a directory, so why do we need a placeholder to say whether it matched a directory or a regular file?

[francislavoie]

Because you can do file {path} {path}/. In which case, which one did it match? That lets you find out.

Basically, things down the line might need to know whether the rewritten thing was a directory or a file, and behave differently based on that. That's the crux of the question in https://caddy.community/t/how-to-determine-if-a-path-is-a-directory-or-a-file/9643

[mholt]

I've been looking at this most of the afternoon and I think I finally understand what is going on... it's a big change!

Thanks for the tests. I'm glad there are some. 😅

[mholt]

Cool, we're almost there I think.

[mholt]

Cool, let's rock and roll.

Thanks for working so diligently on this!