We can also offer both and define a client request parameter (as
long as the server is required to make at least one format available).
+1 on this
regards,
Torsten.
EHL
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Dick Hardt
Sent: Sunday, April 18, 2010 9:30 PM
To: OAuth WG
Subject: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
The AS token endpoint response is encoded as application/x-www-form-
urlencoded
While this reuses a well known and understood encoding standard, it is
uncommon for a client to receive a message encoded like this. Most server
responses are encoded as XML or JSON. Libraries are NOT reedily available to
parse application/x-www-form-urlencoded results as this is something that is
typically done in the web servers framework. While parsing the name value
pairs and URL un-encoding them is not hard, many developers have been
caught just splitting the parameters and forgetting to URL decode the token.
Since the token is opaque and may contain characters that are
escaped, it is a
difficult bug to detect.
Potential options:
1) Do nothing, developers should read the specs and do the right thing.
2) Require that all parameters are URL safe so that there is no
encoding issue.
3) Return results as JSON, and recommend that parameters be URL safe.
-- Dick
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
