Resource creation behaviour when using the `Slug` header
NSeydoux opened this issue · 13 comments
In the current LDP specification, a client is allowed to hint for a resource name at creation time by setting the Slug header in the POST request (see section 5.2.3.10). However, since the usage of the Slug header is quite flexible, the LDP spec does not specify the expected behaviour when requesting for the creation of a resource with a slug that's already present in the parent's containments.
Depending on the implementation, different behaviours may therefore be expected:
- Preventing the creation of a new resource with the same slug altogether, and returning a
409 Conflictresponse to the client, potentially including aLink <iri>; rel="ldp:constrainedBy"header, witiripointing to a vocabulary defining a term specifying "The requested IRI already exists" - Creating the resource combining the slug to a generated ID, and returning the resource IRI to the client in the response's
Locationheader
Since these two behaviours are compliant by the LDP spec, I don't know if imposing one over the other is desirable in the Solid spec, but it may be worth mentioning that these outcomes are possible in the LDP section of the Solid spec, as a non-normative remark.
Do you think this needs to be addressed, and if so as a normative or a non-normative bit ?
That sounds like useful non-normative material. Irrespective of Slug, one way to frame the core case could be based on this given:
LDP servers that allow member creation via
POSTSHOULD NOT re-use URIs.
Servers can implement that recommendation by prohibiting any attempts to update existing resources - 409. A more accurate and complex implementation may examine the representation and determine whether it is within acceptable reuse.
The exact application of Slug to determine the final resource URI is an implementation detail. I don't think that needs to be emphasised.
That sounds like useful non-normative material.
Yup, definitly. Should we put it on the June milestone?
Thinking further..
While servers can choose to handle Slug as they please, it may be preferable for clients that are making the effort in suggesting a URI to be least surprised.
If servers runs into the URI reuse case, it should reject the request instead of creating a resource with a different name. It gives clients the opportunity to be aware of an existing resource with the same name, and resolve the conflict eg. try a different Slug value.
FWIW:
mkdir /tmp
mkdir: cannot create directory ‘/tmp’: File exists
as opposed to creating for example /tmp-foo/.
Moreover, it is worthwhile to note server's environment for security and privacy purposes. That is, if the server returns a 409 and indicates that a resource with the same name exists, it may be exposing information it doesn't necessarily want to. On the other hand, if a resource is generated with a different name than what's suggested in the Slug, it may or may not mean that the desired name necessarily exists. While the client can always try GET, HEAD, OPTIONS to see the existence of a URI, authn/z applies in any case. (See also: #14 )
#107 should be resolved before resolving this issue. Will probably reuse heuristics.
When rereading this issue, I found that there two separate issues that fit pretty well with the headline, but not with the description of @NSeydoux . :-) One is what should be done when there is an existing resource with the same identifier. The other is how the Slug behaves with relation to containers and stuff. The latter, I believe, needs to be normative material. The former, I still think of as a best practice thing.
Servers using the Slug value in the algorithm to generate the new URI SHOULD apply the slash semantics.
new URI SHOULD apply the slash semantics
Given #128 (comment), we might want that to be a MUST.
I think Best Practices note could include guidance on using Slug header. Since client can't rely on server honoring it, probably creating new resource with PUT provides way for client to ensure creation at specific IRI. I think someone developing client may prefer to use reliable PUT than handle case where client hints certain slug but server ignores it.
client may prefer to use reliable PUT than handle case where client hints certain slug but server ignores it
Client always need to be prepared for servers ignoring a slug; slugs are only a suggestion.
Client always need to be prepared for servers ignoring a slug; slugs are only a suggestion.
I tried suggesting use of PUT as best practice to create new resource at specific IRI, instead of POST + Slug. This way client will simply not need to deal with server ignoring the Slug.
Instead of trying to accomplish goal using an unreliable approach, client can simply accomplish same goal using a reliable approach.
Of course, my bad for confusing with POST + slug.
Yes, I think we agree on that, but note that the original issue text is about what to do when there are existing resources.
Perhaps a change of title would clarify?
How about "Behaviour of Slug header when it would collide with an existing resource with the same identifier." Or something like that. What do you think, @NSeydoux ?