URL construction

[m-mohr]

How do other STAC clients solve the issue that e.g. https://example.com/path/to/folder (as a base URL provided by the user or from root/self link) could be a file or folder?

If I resolve a relative link ./item.json against the base URL it would result in https://example.com/path/to/item.json although folder is a folder in my case.

On the other hand, if I resolve ./item.json against a base URL https://example.com/path/to/catalog.json it should of course resolve to https://example.com/path/to/item.json.

I'm hesistant to check for the file extension as files don't necessarily need one, right? Folders could also have dots in them.

Currently, I enforce in the STAC Browser config that people need to add a slash at the end, i.e. https://example.com/path/to/folder/, but it seems many implementations don't follow this. Some even give a 404 with a slash at the end.

Thoughts? Ideas? Is this something we should descibe in the best pactices?

[gadomski]

My preferred convention is:

a trailing slash is significant. Without it, the last path component is considered to be a “file” name to be removed to get at the “directory” that is used as the base

Taken from the join method in rust-url: https://docs.rs/url/latest/url/struct.Url.html#method.join

Whatever we decide, I do think it should be included in best practices.

[m-mohr]

That's a good pointer. I've created a PR on top of it: #1214

[m-mohr]

Just found a good implementation that highlights why detecting the dot (or a "file extension") in a filename is not ideal.
-> https://example.com/collections/USGS.catalog

So all collection IDs there end with .catalog, but it's definitively not a file.