Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-1288

Precisely specify the format of the Error Response

    XMLWordPrintable

    Details

    • Proposal:
      Hide

       Updated proposal from 2019-3-7:

      • We need to specify the format-independent minimal content of an error response body in Protocol
      • code: non-empty string, not null
        -  code: not language-dependent
        -  message: language-dependent, non-empty, not null, human-readable
        -  target: string, can be null, can be omitted, can be empty
      • details: collection of structured instances with code, message, target, same rules as above
      • innererror: optional, structured instance, anything goes
      • Make comment about security concerns "global" to error response, not only specific to innererror

       

      Change paragraphs 3 to 5 in chapter 21 Error Response:

      The value for the code name/value pair is a language-independent string. Its value is a service-defined error code. This code serves as a sub-status for the HTTP error code specified in the response.

      The value for the message name/value pair MUST beis a string containing a human-readable, language-dependent representation of the error. The Content-Language header MUST contain the language code from [RFC5646] corresponding to the language in which the value for message is written.

      The value for the target name/value pair is a string containing the target of the particular error (for example, the name of the property in error).

      Neither code nor message can have the value null.

       

       

       

      Show
       Updated proposal from 2019-3-7: We need to specify the format-independent minimal content of an error response body in Protocol code: non-empty string, not null -  code: not language-dependent -  message: language-dependent, non-empty, not null, human-readable -  target: string, can be null, can be omitted, can be empty details: collection of structured instances with code, message, target, same rules as above innererror: optional, structured instance, anything goes Make comment about security concerns "global" to error response, not only specific to innererror   Change paragraphs 3 to 5 in chapter 21 Error Response: The value for the code name/value pair is a language-independent string. Its value is a service-defined error code. This code serves as a sub-status for the HTTP error code specified in the response. The value for the message name/value pair MUST be is a string containing a human-readable, language-dependent representation of the error. The Content-Language header MUST contain the language code from [RFC5646] corresponding to the language in which the value for message is written. The value for the target name/value pair is a string containing  the target of the particular error (for example, the name of the property in error). Neither code nor message can have the value null .      
    • Resolution:
      Show
      https://www.oasis-open.org/committees/download.php/64833/odata-json-format-v4.01-wd06-2019-03-08.docx https://www.oasis-open.org/committees/download.php/64834/odata-v4.01-wd06-part1-protocol-2019-03-08.docx

      Description

      The current specification text does not explicitly specify that message and target are strings, and whether they can be null.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              handl Ralf Handl
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: