Clarify recursive container creation on POST, PATCH and PUT

[dmitrizagidulin]

As was mentioned in the semantics of PUT discussion, we need to decide on a consistent policy for recursive container creation for various resource types (Resources and Containers) and via the 3 major creation verbs (PUT, PATCH and POST).

(Also sometimes referred to as mkdir -p semantics)

Current behavior (in Node Solid Server):

• PATCH - creating a resource: Intermediate containers are automatically created.
• PATCH - creating a container: Yes. Technically this gets parsed as a PATCH to a container's .meta
• POST - creating a resource: Does not create intermediate container, throws a 404 Not Found.
• POST - creating a container: same as above.
• PUT - creating a resource: Intermediate containers are automatically crated (mkdir -p style).
• PUT - creating a container: Not currently supported, but hopefully will be

[acoburn]

Some clarifying questions:

• By "Current behavior", I assume Node Solid Server is meant. That may not apply to other implementations
• Is it possible to create resources via PATCH? LDP does not explicitly take a position on this, though all examples show PATCH as a mechanism for updating an existing resource. RFC 5789 states that PATCH MAY be used to create resources. See also related issue: Methods for ACL resource creation #42
• With POST, are you referring to a case where the target URL of the request does not exist? Wouldn't a 404 be returned in that case?
• Or is the interaction that a client POSTs to an extant container but that request causes the creation of a new container hierarchy (e.g. with a Slug header that includes slashes?) And what if an implementation rejects such requests?

I would note that a RESTful design would tend to avoid side affects: i.e. a PUT to /foo/bar/baz that simultaneously creates /foo, /foo/bar and /foo/bar/baz might be considered problematic.

[dmitrizagidulin]

@acoburn Yeah, I just meant 'current NSS behavior' (I edited the comment to clarify).

Is it possible to create resources via PATCH?

In nss, yes, and I believe a lot of @timbl's Data Browser / mashlib code relies on this functionality. As in, this is not incidental, but definitely part of the spec.

With POST, are you referring to a case where the target URL of the request does not exist?

Right, ok, I just double checked, and NSS currently does return a 404 / target url does not exist.

Can definitely confirm that NSS PUT does create intermediate containers, mkdir -p style.

[kjetilk]

I would note that a RESTful design would tend to avoid side affects: i.e. a PUT to /foo/bar/baz that simultaneously creates /foo, /foo/bar and /foo/bar/baz might be considered problematic.

Indeed, but the implications of the slash semantics design seems to require this behaviour.

[timbl]

• PATCH - creating a resource: Intermediate containers are automatically created.

Absolutely. My code uses this a lot. To add a chat message to a file in a dated set of files like /Archive/Public/2009/10/12/chat.ttl it is really valuable that the mkdir -p happens. Would be much slower to have to do the mkdir -p on the client side.

We need it well documented and also well documented that it will also the file itself.

[kjetilk]

With the resolutions that Solid containment is strictly hierarchical (#98) and the resolution on slash semantics in #35 , this can be moved to rough concensus.

[kjetilk]

I just looked into what databrowser does when creating a container, and it seems to always create a resource, even if it doesn't need it, e.g., from the server log:

  solid:ACL Using ACL https://solid.kjernsmo.net/public/.acl for ./testfolder/.dummy +3m
[...]
  solid:put /public/testfolder/.dummy +0ms
[...]
  solid:handlers PUT -- Wrote data to: /var/www/solid.kjernsmo.net/data/public/testfolder/.dummy$.txt +1ms
  solid:put succeded putting the file +0ms
  solid:ACL Using ACL https://solid.kjernsmo.net/public/.acl for ./testfolder/ +97ms
[...]
  solid:handlers DELETE -- Request on/public/testfolder/.dummy +0ms
  solid:handlers DELETE -- Ok. +1ms

Is this behaviour intended? Shouldn't it be possible to create an empty container?

[RubenVerborgh]

Security follow-up on the current resolution in #129.

[csarven]

Proposal following meeting of 2019-12-04T15:11:00Z:

Following #35 #98 , based on client and server agreement on slashes and hierarchical assumption, server creates containers and containment relations for create methods.