[OASIS Issue Tracker] Updated: (ODATA-283) Accept-Charset HTTP Request Header and charset content-type parameter

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/ODATA-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Pizzo updated ODATA-283:
--------------------------------

    Proposal: 
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.

  was:
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

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.


> Accept-Charset HTTP Request Header and charset content-type parameter
> ---------------------------------------------------------------------
>
>                 Key: ODATA-283
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-283
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData JSON Format, OData Protocol 
>    Affects Versions: V4.0_WD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_WD01
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira