[Openid-specs-ab] Content-Type Charset header questions

[Brian Campbell]

I'll give my input though I wouldn't use the word "expert" anywhere near it.

My understanding is that charset shouldn't be included with
application/json. See
http://stackoverflow.com/questions/13096259/can-charset-parameter-be-used-with-application-json-content-type-in-http-1-1and
particularly the response from Julian Reschke. Although examples in
RFCs 6749 and 6750 do include it (and so does my own software for that
matter) so I'm a little unsure what should be done in Connect.

I think you are correct that the charset should be removed from the
Content-Type: application/x-www-form-urlencoded POST example in Basic. That
was done in -29 of what would become RFC 6749
http://tools.ietf.org/html/draft-ietf-oauth-v2-31#appendix-D and Julian
also gave some reasoning about the content type and encoding in general at
http://tools.ietf.org/html/rfc6749#appendix-B


On Mon, Jan 21, 2013 at 12:44 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  Basic contains two instances of HTTP Content-Type headers with a
> ;charset=UTF=8 clause.  These clauses aren’t present in the corresponding
> examples in Messages or Standard.  I think they should be made consistent.
> I’d like input from experts on the list.****
>
> ** **
>
> The first example in Basic is:****
>
> POST /token HTTP/1.1****
>
> Host: server.example.com****
>
> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW****
>
> Content-Type: application/x-www-form-urlencoded;charset=UTF-8****
>
> ** **
>
> grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA****
>
> &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb****
>
> whereas the corresponding example in Standard is:****
>
> POST /token HTTP/1.1****
>
> Host: server.example.com****
>
> Content-Type: application/x-www-form-urlencoded****
>
> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW****
>
> ** **
>
> grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA****
>
> &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb****
>
> ** **
>
> In this case, I think the clause should be removed from Basic.  I think I
> remember that form-urlencoded doesn’t support a charset attribute, from
> OAuth Bearer discussions.****
>
> ** **
>
> The second example in Basic is:****
>
> HTTP/1.1 200 OK****
>
> Content-Type: application/json;charset=UTF-8****
>
> Cache-Control: no-store****
>
> Pragma: no-cache****
>
> {****
>
>   "access_token":"SlAV32hkKG",****
>
>   "token_type":"bearer",****
>
>   "expires_in":3600,****
>
>   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",****
>
>   "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"****
>
> }****
>
> whereas the corresponding example in Standard is:****
>
> HTTP/1.1 200 OK****
>
> Content-Type: application/json****
>
> Cache-Control: no-store****
>
> Pragma: no-cache****
>
> ** **
>
> {****
>
> "access_token": "SlAV32hkKG",****
>
> "token_type": "Bearer",****
>
> "refresh_token": "8xLOxBtZp8",****
>
> "expires_in": 3600,****
>
> "id_token": "eyJhbGciOiJSUzI1NiJ9.ew0K…"****
>
> }****
>
> ** **
>
> I’ll note that the example in Section 4 of RFC6750 does include the
> charset.  Thus, I think it should be added to Standard in this case.****
>
> ** **
>
> FYI, this is part of me working on issue #655: All - Specify UTF-8 as
> encoding scheme whenever necessary.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130121/f359c28a/attachment.html>