[JAMES-3097] Implement level error-handling protocol

• Type: Sub-task
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Assignee: Unassigned
• Reporter: René Cordier
• Created: 06/Mar/20 09:31
• Updated: 29/Sep/20 04:53
• Resolved: 09/Mar/20 09:08

Description

See https://jmap.io/spec-core.html#errors notes about Request-Level Errors:

When an HTTP error response is returned to the client, the server SHOULD return a JSON “problem details” object as the response body, as per [RFC7807](https://tools.ietf.org/html/rfc7807).

The following problem types are defined:

• urn:ietf:params:jmap:error:unknownCapability The client included a capability in the “using” property of the request that the server does not support.
• urn:ietf:params:jmap:error:notJSON The content type of the request was not application/json or the request did not parse as I-JSON.
• urn:ietf:params:jmap:error:notRequest The request parsed as JSON but did not match the type signature of the Request object.
• urn:ietf:params:jmap:error:limit The request was not processed as it would have exceeded one of the request limits defined on the capability object, such as maxSizeRequest, maxCallsInRequest, or maxConcurrentRequests. A “limit” property MUST also be present on the “problem details” object, containing the name of the limit being applied.

Example

{
  "type": "urn:ietf:params:jmap:error:unknownCapability",
  "status": 400,
  "detail": "The Request object used capability
    'https://example.com/apis/foobar', which is not supported
    by this server."
}

DOD:

• Ommitting the content-type, accept header, sending non json payload, invalid json payload, or violating limits should result in the right error. You will write memory integration tests demonstrating these protocol errors.