POST not allowed for auxiliary resources

[bourgeoa]

@csarven @michielbdejong @jeff-zucker

When a POST method request with the Slug header targets an auxiliary resource, the server MUST respond with the 403 status code and response body describing the error. [Source]

This is taken from specification. It does not seem to fit well with : PR #1527

When a DELETE request targets storage’s root container or its associated ACL resource, the server MUST respond with the 405 status code. Server MUST exclude the DELETE method in the HTTP response header Allow in response to safe method requests [RFC7231]. [Source]

Why not use 405 for both and exclude the method from the headers response ? Is there a conflict with http specifications ?

When I look at it from the error code side it seems also easier to understand for Solid users and devs : This is certainly a simplification.

• 400 do not exist (resource, content-type, ...)
• 401 user has no authorization (not logging ...)
• 403 user is not allowed ( relates to user permission...)
• 405 method is not allowed in this request (DELETE for root, POST for auxiliary resources, ...)
• 409 conflict (cannot delete container with resources, cannot inserts with patch when deletes fails, cannot create a resource with the same name than an existing container, ...)
• 415 exist but unknown (content-type mime-type is unknown, ...)

[csarven]

Servers can potentially respond with 405 on any resource. 405 is a special case for the root container and the directly associated ACL resource for authorized requests. 403 can come before 405 for unauthorized requests so as to not disclose the location of either, in theory for the root container / pim:Storage (but that can generally be determined in cases where root is the initial / segment in URI path), but more realistically for the ACL auxiliary resource. ACL location can only be known/discoverable by agents with Control access on the resource that's directly associated with the ACL resource.

POST targeting an existing (non-container) resource is currently unspecified but can default to append, or possibly get rejected with 415 because of unsupported. That's pretty much RFC 7231. If/when RDF merge comes in, that will work within that.

POST targeting an existing auxiliary resource is just 403. 403 beats 405 here because server shouldn't necessarily disclose the existence of the resource. It could be argued that for authorized requests, 405 could work here as well, but as the RFC goes, it could be forbidden for reasons other than credentials. If requester can know the difference between 403 and 405, they can potentially know if that auxiliary resource exists. Sticking to 403 doesn't reveal that either way.

POST targeting an existing container with or without Slug is supposed to create a new resource under a container. If it so happens to be that server uses the Slug value as is ie. targeting an auxiliary resource when combined with the target request URI ie. the effective request URI, then 403 is good in that requester simply can't create that resource - whether they are authorized to write under that container or not.

Having said that, there are different ways to approach this and above just happens to be one. I'm happy to hear more arguments or implementation experience.

(I may edit the above for clarity later.. just wrote this in one go.)