A fuller static web server for public resources (directory index, trailing-slash redirects, …) #105

Public resources are served by a fallback in NGApplication.noHandlerResponse(): a request no route handles is looked up as a public resource, which makes ng "essentially a plain web server" for files under public/ (the CHECKME's words, 2023). Today it serves files by exact path, and nothing more.

This came up with ng-website's public/glytta/index.html: /glytta/ answered 500, because the classpath lookup treated the directory as a resource. That's fixed separately (a directory is never a resource, so it's a 404 now). What's left is whether ng should serve static sections more fully, as a web server does. It was decided against doing it implicitly for now: it would compete invisibly with the route table, and being strict first is easier than taking behaviour away later.

What a fuller static server would involve, if it becomes a feature:

• Directory index: /section/ serves section/index.html.
• Trailing-slash redirects: /section redirects to /section/ when it's a directory, so relative links inside its pages resolve against the right directory. This comes as a pair with the index; one without the other breaks relative links.
• Opt-in and visible: probably declared rather than implicit, for example mapping a URL prefix to a public directory in the route table, so what serves a URL stays visible where pages are defined.
• Namespaces: the fallback is hard-wired to the app namespace, which is the open FIXME on noHandlerResponse().
• The rest of what a web server does for static files, each worth deciding on: Range requests (resumable downloads, media seeking), Last-Modified/If-Modified-Since alongside the ETags, compression of text resources (or pre-compressed .gz/.br variants), and content types for extensions not yet in NGMimeTypes.
• Path safety: a lookup that maps URLs to files must never escape the public directory (.., encoded separators). The classpath lookup can't today, but a file-system source would have to make sure.

In deployment a front web server often serves static folders, so part of the question is how much of this belongs in ng at all.