Description
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 Conflict
response to the client, potentially including aLink <iri>; rel="ldp:constrainedBy"
header, witiri
pointing 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
Location
header
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 ?