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

Accept-Charset HTTP Request Header and charset content-type parameter

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: V4.0_WD01
    • Fix Version/s: V4.0_WD01
    • Component/s: JSON Format, Protocol
    • Labels:
      None
    • Environment:

      [Proposed]

    • Proposal:
      Hide

      Specify in Part 1: Protocol that:

      • The Accept-Charset request header MUST have priority over a charset= format parameter in the Accept header.
      • The charset= format parameter MUST be taken into account if no Accept-Charset header is provided

      Revised from 2013-3-21 meeting:
      The service MUST NOT return a charset=format parameter unless specified in the request.
      Specify in JSON Format that:

      • The charset=utf-n format parameter is unnecessary in the Content-Type header as the actual encoding can be determined from the first four octets in the response, see http://tools.ietf.org/html/rfc4627#section-3, so services MUST NOT put it in responses unless specified in the request.

      Accepted: https://www.oasis-open.org/committees/download.php/48622/odata-meeting-30_on-20130321-minutes.html#odata-283

      Show
      Specify in Part 1: Protocol that: The Accept-Charset request header MUST have priority over a charset= format parameter in the Accept header. The charset= format parameter MUST be taken into account if no Accept-Charset header is provided Revised from 2013-3-21 meeting: The service MUST NOT return a charset=format parameter unless specified in the request. Specify in JSON Format that: The charset=utf-n format parameter is unnecessary in the Content-Type header as the actual encoding can be determined from the first four octets in the response, see http://tools.ietf.org/html/rfc4627#section-3 , so services MUST NOT put it in responses unless specified in the request. Accepted: https://www.oasis-open.org/committees/download.php/48622/odata-meeting-30_on-20130321-minutes.html#odata-283
    • Resolution:
      Show
      Applied: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/48762/odata-core-v4.0-wd01-part1-protocol-current-2013-4-5MP.docx Accepted: https://www.oasis-open.org/committees/download.php/49026/odata-meeting-34_on-20130425_26-F2F-minutes.html#odata-283

      Description

      The Accept-Charset request header is defined by RFC2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.2 ), so OData services SHOULD take it into account.

      On the other hand some JSON libraries issue requests with Accept: application/json;charset=utf-n, so OData services SHOULD take that into account, too.

      SHOULD is a pain for interoperability, so let's specify MUST.

      There are two ways to specify the charset, so we either have to force servers to reject conflicting statements, or define a precedence rule. The latter is friendlier, so we choose it.

      RFC2616 is a standard, and appending a format parameter to the media type is just a practice, so the Accept-Charset header takes precedence.

      The actual charset of a JSON payload can be determined from the first four octets (http://tools.ietf.org/html/rfc4627#section-3 ), so the format parameter is not necessary in the Content-Type header, and servers needn't include it. Again choice for servers is bad, so they MUST NOT include it.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: