List items in bucket

[ben476]

A handy feature would be the ability to list objects. I was thinking maybe if on a get request a file isn't found, try list objects with the the path as the prefix.

I can do a PR if you think this is a good idea.

[kotx]

Yeah, I was thinking of implementing this, but I wasn't sure how/if I should check if a "directory" should be listed- would it be a file called .list in the root of the directory? Or is there something that's more intuitive? Also, if it's implemented, I think there should at least be a global setting for it, in the form of an environment variable. Would the directory listing be JSON or HTML? (If HTML, I would prefer for it to look like nginx so it's more parseable) etc. Maybe we can parse the accept header? If you have any ideas, please share!

[ben476]

Your ideas sound great! I think it's important to have every directory be listed by default, as the vibe I'm getting from this project is "a super easy way to publicly expose r2", and have options to enable checking for .list or not to list directories by default. Parsing the accept header sounds good. I would much rather add an extra header to my fetch() rather than have to parse any sort of HTML. If we include the option to return JSON, would you still want the HTML to look like nginx or maybe something nicer?

[kotx]

I think it's important to have every directory be listed by default, as the vibe I'm getting from this project is "a super easy way to publicly expose r2", and have options to enable checking for .list or not to list directories by default.

That sounds good, I think if listing is enabled (so DIRECTORY_LISTING = true under [vars] in wrangler.toml or similar), it should check for /prefix/.nolist, otherwise it disables listing completely (or checks for .list, up to you).

I think the HTML should be relatively simple, preferably no external resources should be loaded and no JS. But it can look nice, as long as there isn't like 1000 lines of HTML or something. I'm not sure what file data to expose, though. Ideally there isn't a HEAD request for every single file in the directory, but I'll have to see what metadata is exposed in list.

It would be awesome if you want to send a PR for this, even if it only implemented a fraction of this. If not, let me know and I'll gladly do it myself. Thanks for the feedback!

[ben476]

Sure! I'll get it done when I have time.

I'm just thinking that .nolist and .list would be features that won't be used often, but also have the downside of slowing down requests because of the extra head request. Maybe it could be optional?

[kotx]

I'm just thinking that .nolist and .list would be features that won't be used often, but also have the downside of slowing down requests because of the extra head request. Maybe it could be optional?

You're right, maybe we don't need it. I'll try to think of an alternative in the meantime. Maybe an object with the same name as the directory? Since we have to check for it anyway.

[ben476]

An idea I had was using the VS code icon set, which has icons for each file extension or folder name. What do you think?

We could host the icons in a Cloudflare Pages project and link to them when the list page is generated.

[kotx]

Hmm, I'm not sure if that would be used often, though. Do people typically host code, etc under S3 buckets? It seems like a lot of the icons in the bundle wouldn't be used. I would prefer simpler icons, like Chalice, and not have any external dependency on another Pages project, etc. Basically, for accessibility I want to be able to view it through lynx easily. For example, making it look good with sakura would be better than something like a full-blown vue application.

[zadeviggers]

What do you think of this design? It's just html and css. I've also written a little function that takes a list of files and breadcrumbs and generates the html, for use in the worker. The icon pack is Feather Icons.

[ben476]

Hmm, I'm not sure if that would be used often, though. Do people typically host code, etc under S3 buckets? It seems like a lot of the icons in the bundle wouldn't be used.

Very true. The VS code icon set does have a wide range of icons for all sorts of files, but there's also way too many icons for code.

I would prefer simpler icons, like Chalice, and not have any external dependency on another Pages project, etc.

Yeah, you're right, everything should be inside this repo. Something like Chalice would be nice, but common formats for S3 buckets like video, archives, and audio would all be just "other" and have the same icon... Feather Icons as suggested by @zadeviggers may be promising?

Basically, for accessibility I want to be able to view it through lynx easily. For example, making it look good with sakura would be better than something like a full-blown vue application.

Cool, I'll keep that in mind. I'm just using a giant JS template string right now. The one zadeviggers made looks good though.

[kotx]

@zadeviggers What do you think of this design? It's just html and css. I've also written a little function that takes a list of files and breadcrumbs and generates the html, for use in the worker.

This looks good! One personal preference, but not a requirement, is if the layout were from top-to-down then left-to-right, because that's usually how things are displayed, I think. Sort of like the Windows File Explorer?

@ben476 Something like Chalice would be nice, but common formats for S3 buckets like video, archives, and audio would all be just "other" and have the same icon... Feather Icons as suggested by @zadeviggers may be promising?

Yup, I didn't think of that, I think Feather would be good if we have all those icons. We should categorize with content-type rather than filenames if possible, but if they aren't returned in a list operation, we might have to use filenames.

@ben476 Cool, I'll keep that in mind. I'm just using a giant JS template string right now. The one zadeviggers made looks good though.

:+1: Sounds good!

[kotx]

The way Caddy does it is a browse.html that gets templated. Maybe this would be a better solution?

[kotx]

Added support for some basic listing for now in #20, looks good to me so closing! Will version bump and release shortly.

[kotx]

Released 1.0.0 in 52a7521! 🎉