Helmut Richter, 2023-01-02 15:35:

[...]
> Now I have two ways to store web contents in the file system:
>
> classical: the URL <domain>/a/b/c is served from file <doc-root>/a/b/c/index.ext
> which a suitable file extension (as a means to determine the content type),
> typically .html
>
> abbreviated: the URL <domain>/a/b/c is served from file <doc-root>/a/b/c.ext
> provided that there is no directory /a/b/c
[...]
> Are there any other reasons to prefer one of the methods over the other?

I would stick with <doc-root>/a/b/c/index.ext and not allow the
alternative <doc-root>/a/b/c.ext for the same URL to avoid confusion
what <doc-root>/a/b/c means in your filesystem.

--
Arno Welzel
https://arnowelzel.de

On Thu, 5 Jan 2023, Arno Welzel wrote:

> Helmut Richter, 2023-01-02 15:35:
>
> [...]
> > Now I have two ways to store web contents in the file system:
> >
> > classical: the URL <domain>/a/b/c is served from file <doc-root>/a/b/c/index.ext
> > which a suitable file extension (as a means to determine the content type),
> > typically .html
> >
> > abbreviated: the URL <domain>/a/b/c is served from file <doc-root>/a/b/c.ext
> > provided that there is no directory /a/b/c
> [...]
> > Are there any other reasons to prefer one of the methods over the other?
>
> I would stick with <doc-root>/a/b/c/index.ext and not allow the
> alternative <doc-root>/a/b/c.ext for the same URL to avoid confusion
> what <doc-root>/a/b/c means in your filesystem.

Thank you. After doing some testing with different configurations, I come to
the same result: this feature is really confusing.

E.g.: if <doc-root>/a/b/c.html is called by the path /a/b/c, relative URLs
(href="xyz") are relative to the fictitious directory /a/b/c. If, however,
<doc-root>/a/b/c.html is called as /a/b/c.html, relative URLs are, of course,
relative to the real parent directory /a/b. Same file contents, same file
name, same place in the dir tree, different semantics. Moreover, you can even
call the same file as /a/b/c/index.html even though /a/b/c does not exist,
then the spurious file name is treated as PATH_INFO.

So it should indeed not be allowed, as you suggest. It took me a while to
find out why weird things like paths to nonexistent directories and files
were allowed in the first place, and what to do to disallow them. The main
point was the MultiViews option which brings about most of the mess.

I will now use the following options as defaults:

Options All {disallows MultiViews}
Options -Indexes
DirectoryIndex index.html index.txt {and perhaps others, as needed}
AcceptPathInfo Off {unless needed for good reasons}

Then the path in the URL must be a valid file path resulting in a directory
(then one of index.* must exist there) or in an existing file. In all other
cases, a 404 or 403 status is returned. Simple rules, less problems.

--
Helmut Richter