Should we allow slugs ending on a slash to create containers?

[joachimvh]

I'm ok with either since I don't know what the current accepted standard is

https://www.w3.org/TR/ldp/#ldpc-post-createrdf says:

Clients use the same syntax, that is HTTP Link headers, to specify the desired interaction model when creating a resource as servers use to advertise it on responses.

So as far as I understand, client can (only) create containers by having a Link header for a basic container. We might want to resolve that in a new issue. @csarven?

Originally posted by @RubenVerborgh in #620 (comment)

[csarven]

client can (only) create containers by having a Link header for a basic container.

That's correct for LDP and Solid Protocol.

---

From the point of LDP compatibility with Slug support, that should result in the creation of a new container whether slugtext ends with a slash or not.

From the point of Solid Protocol compatibility with Slug support, I'll refer to my earlier comment and considerations on Slug here: #574 (comment) .

The Solid Protocol allows some variability. To be clear, CSS is not required to support Slug or slugtext with slashes or only those ending with a slash, but that it should be consistent and careful in how it handles it.

If request includes the Link header with BC, normalize based on that (regardless of Slug and slugtext ending with slash) and create the container.

CSS doesn't need create a container if POST doesn't include the Link header, but say it is allowing when Slug and slugtext ends with a slash. Still the considerations mentioned in the comment holds.

Aside: I'll update the Protocol with a Note on Slug considerations.

[kjetilk]

You might have noticed in earlier discussions that I came out in favor of using slugs to create containers, but in the subsequent discussion, it became clear that we need to carefully constrain slugtext to do it. So, I guess my response is "hopefully later, but not yet".