Precedence of response codes

[kjetilk]

Consider, for example the request:

PUT /test-put-bc/dahut-bc.ttl
Authorization: Bearer SoOP3RS1krIT
If-None-Match: *
User-Agent: libwww-perl/6.36
Content-Type: text/turtle
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

@prefix dc: <http://purl.org/dc/terms/>.
<> dc:title "Container Interaction Model"@en .

If the resource already exists, there are two different reasons why this request should fail:

• It should fail with a 409 because ldp:BasicContainer is inconsistent with that the request URI does not end with a /.
• It should fail with a 412 because it failed the precondition set by the If-None-Match: * header.

In such cases, should we express what should be checked first, IOW, what error message the client should see in every case, or should we leave that up to implementations?

[csarven]

Hmm good question. So, I think given #128 (comment) my understand is that, this should happen:

Create a container with server determined identifier appended to the request-URI.

There wouldn't be a 409 but the possibility of /test-put-bc/dahut-bc.ttl/ getting created as a container.

That might just mean that 412 will kick in.

---

Let's make sure to identify other situations where multiple error codes may be applicable. For instance, authn/z based errors (or hiding sensitive information eg. via 404) should (probably must) precede other kind of errors. So, we can start by ordering error categories.

Edit: I think we should eliminate situations where an implementation needs to choose a response code at random or based on its preferences - as much as possible. There should be a clear decision path.

[csarven]

Would it make sense to reframe this issue to "Precedence of response codes"? It is not entirely about errors as this example shows #107 (comment) :

Server MAY redirect a request with 301 from a non-existing URI to an existing URI with a matching path component ending with the same segment term. Behaviour pertaining to authorization MUST proceed this optional redirect.

So, in that case if 403 is applicable, it should happen.

[csarven]

Haven't verified the following. Check back later:

• https://web.archive.org/web/20200314033029/https://raw.githubusercontent.com/for-GET/http-decision-diagram/master/httpdd.png
• https://web.archive.org/web/20190729063353/https://www.loggly.com/wp-content/uploads/2015/06/http-decision-diagram.png

[csarven]

Revisiting this issue with specifics to the example in #146 (comment) based on current spec:

Server will ignore the Link header because the slash semantics determine the type of resource. Only in the case of server assigning the URI of a container via POST the Link header with a LDP container type will be used.

409 can only happen with respect to https://tools.ietf.org/html/rfc7232#section-5 :

redirects and failures take precedence over the evaluation of
preconditions in conditional requests.

eg. changing the identity of the resource, which may the case for instance if the representation body included <> a ldp:Container and so the server rejects given that the original resource is a non-container.

Besides such cases, server will return 412.

[kjetilk]

This will be important as we write tests, so I suggest we prioritize it. It is also related to #288 .

It might be sensible to leave some variability here though, that there is no precedence. If that is the conclusion, clients, including tests, will need to consider several error scenarios. It might work out fine.