HTTP Error codes for conflict management are backwards

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • Normative
    • REST (http)
    • 3.1.0.11
    • Hide

      The current spec on resource contention uses a 412 to express that a precondition of the server ("you should provide an if-match") has failed, however the HTTP spec clearly says about 412:

      "This response code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state."

      So, we are using this incorrectly. On re-reading the HTTP spec we think this should be changed into:

      • When there is an If-Match, and the condition failes: return 412
      • When the server requires the precondition header (if-match) and it is not supplied we need to return 400
      • We can still add that 409 can be used when the server detects the update cannot be done due to say pessimistic locking.
      Show
      The current spec on resource contention uses a 412 to express that a precondition of the server ("you should provide an if-match") has failed, however the HTTP spec clearly says about 412: "This response code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state." So, we are using this incorrectly. On re-reading the HTTP spec we think this should be changed into: When there is an If-Match, and the condition failes: return 412 When the server requires the precondition header (if-match) and it is not supplied we need to return 400 We can still add that 409 can be used when the server detects the update cannot be done due to say pessimistic locking.
    • Dennis Patterson/Marc de Graauw: 15-0-0
    • Correction
    • Non-compatible
    • STU3

      From the page:

      "If the version id given in the If-Match header does not match, the server returns a 409 Conflict status code instead of updating the resource.

      Servers can require that clients provide an If-Match header by returning 412 Pre-condition failed status codes when no If-Match header is found."

      This is backwards from the HTTP spec, and is also called out pretty specifically for the PATCH method RFC: https://tools.ietf.org/html/rfc5789#section-2.2

      "Conflicting state: Can be specified with a 409 (Conflict) status code when the request cannot be applied given the state of the resource. For example, if the client attempted to apply a structural modification and the structures assumed to exist did not exist (with XML, a patch might specify changing element 'foo' to element 'bar' but element 'foo' might not exist).

      Conflicting modification: When a client uses either the If-Match or If-Unmodified-Since header to define a precondition, and that precondition failed, then the 412 (Precondition Failed) error is most helpful to the client. However, that response makes no sense if there was no precondition on the request. In cases when the server detects a possible conflicting modification and no precondition was defined in the request, the server can return a 409 (Conflict) response."

      We should update the spec to state that 412 should be used when a precondition has been passed in the header, and 409 when other conflict detection (eg: based only on data in the body) has caused the requrest to fail. This brings the spec in line with HTTP preconditions logic as well as PATCH.

            Assignee:
            Unassigned
            Reporter:
            Jenni Syed
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: