Sounds helpful if you're using an existing server that can run PHP. I use dufs (https://github.com/sigoden/dufs) as a standalone lightweight file server, sometimes reverse-proxied into an existing site.
I was fed up with nextcloud and replaced it with syncthing (for laptop/desktop) + dufs + wedav for mobile access, all hosted on a pi@home, accessed through a wg VPN.
Thanks for sharing. I wasn't aware of dufs and it looks very solid. Fileserver[0] is another popular choice, though it's more GUI-oriented for file operations.
The demo is kinda neat. I like the multi-select to download as a tarball and how you can add HTML headers and footers to folders. But it doesn't seem like it's designed for mobile and takes a moment to load. Something similar with server side rendering seems better.
I think it's hardcoded into h5ai. I am not logged into github, so I can't use regular code search, but it seems to refuse to serve anything under $APP_PATH.
I might be misunderstanding. But the instructions just say to set it as a fallback index. So I don't think its own code would run if you requested these files directly because they exist.
> Add /_h5ai/public/index.php (note the leading slash!) to the end of the default index-file list. In this way h5ai will manage all directories in and below DOC_ROOT that don't have a index file.
I click on “search and filter”, it get selected, another click, it navigates to it. And on the new page, “archive.zip” is selected, simply because it is on the same position where “search and filter” was.
I understand that https://larsjung.de/h5ai/demo/special%20chars/screenshot.jpg is a link to the actual file itself, but it would still be nice to have the preview itself be linkable - and be navigable via the back/forward buttons, browser history etc.
So how about using a fragment hash here? https://larsjung.de/h5ai/demo/special%20chars/#file:screensh... (that's the directry URL with #file:screenshot.jpg at the end of it) - that way the back/forward buttons could work, the preview would be linkable and there wouldn't be confusion with the actual URL to the file.
this is really buggy and feels oldweb in a unpleasant way. like newer than visiting a site with no index page and seeing the vanilla apache file directory, but only enough to use old jquery-ish 2003 era web ui/patterns/components.
clicking a file and a big spinner appearing. hitting back button to go back up a few folders, spinner never goes away, etc.