Allow creating containers using PATCH

[NoelDeMartin]

Up until recently, I had been using POST requests to create new containers in my apps and it was working as expected. This sufficed so far because I was hard-coding the path of containers into my apps, and they were always root-level containers. But for a new app I'm working on I let users decide the path of the new container, and this creates a new situation where intermediate containers may not exist.

In order to solve this, I looked at the Solid spec and saw this:

Servers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT and PATCH requests.

So I refactored my code to use PATCH instead. But I found out that it does not work as expected with NSS. Here's the result I've been getting:

curl 'https://localhost:8443/kitchen/cookbook/' \
	-X PATCH \
	-H 'content-type: application/sparql-update' \
	-H 'link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"' \
	-H 'if-none-match: *' \
	-H 'authorization: DPoP ...' \
	-H 'dpop: ...' \
	--data-raw 'INSERT DATA { <> <http://www.w3.org/2000/01/rdf-schema#label> "Cookbook" . }'

Response: Index file needs to have text/html as content type

[bourgeoa]

PUT should work. Could you try PUT without content-type content-type for container should not be needed ?
I don't understand your use of slug
PATCH should only work on Document Resource

Can't write file: PUT not supported on containers, use POST instead

This error code do not exist anymore
What is your NSS version ? On recent versions PUT on container works.

[NoelDeMartin]

Thanks @bourgeoa!

Turns out I was using an old version of NSS locally and I didn't realize 😅, sorry about that. I tried using PUT and it works as expected, so I think that's what I'll do in my apps.

I don't understand your use of slug

I was using that header to create containers using POST, but you're right that it's not necessary using PUT.

PATCH should only work on Document Resource

Where is that specified? Reading the current spec I didn't find anything about it.

This is not a problem for my app anymore, because PUT seems to work for my use-case. But given that this is potentially a conflict with the spec I think I should leave this issue open. If you can clarify where that part is documented, I'll close the issue (or feel free to close it yourself :D).

[bourgeoa]

PATCH can only use N3 patch for the time being

[NoelDeMartin]

@bourgeoa Just to clarify though, is that a limitation of node-solid-server or is that part of the Solid Protocol?

[bourgeoa]

I understand that PATCH in Solid his limited to RDF documents. It can create a new document Resource if not exist and all intermediate container Resources. As such it cannot create a Container only. Container representation is not directly writable.
The specification only consider N3 PATCH.

@csarven is this correct.

[csarven]

This issue is a duplicate of #1465 with the main difference being the HTTP method. Servers are expected to support PATCH to create resources (including containers and non-containers). See also https://solidproject.org/ED/protocol#server-put-patch-uri-assignment

[zg009]

@csarven The link to the #server-put-patch-uri-assignment is broken. Is there another place to find that link, or has it been removed from the spec?

[bourgeoa]

Should be closed.

[csarven]

The requirement https://solidproject.org/ED/protocol#server-put-patch-uri-assignment is dropped. See the ED changelog ( https://solidproject.org/ED/protocol#changelog ).

---

@prefix spec: <http://www.w3.org/ns/spec#> .
@prefix ed: <https://solidproject.org/ED/protocol#> .

ed:changelog
  spec:change ed:a91960b6-0543-4acc-8153-689c435c7659 .

ed:afd2402a-3174-4f27-af9d-f80461538e95
  a spec:Change ;
  spec:changeClass spec:ChangeClass2 ;
  spec:changeSubject ed:server-put-patch-uri-assignment ;
  spec:statement "Remove the requirement for implicit and inherited URI assignment after HTTP PUT, PATCH requests that is already defined in referenced specifications."@en .