On Fri, May 7, 2010 at 11:28 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
>
> Again, for the server, this is just a single printf() statement per format:
>
> printf("{\"access_token\":\"%s\",\"expires_in\":%d}", token, expires);
> printf("<oauth><access_token>%s</access_token><expires_in>%d</expires_in></oauth>",
> token, expires);
>
> For the client, if they don't like the default, you can use the Accept header
> or a 'format' query parameter.
>
> Show me where this is more complex!
You can't actually use printf to produce this output in any quality
implementation, especially if you want to support extension
parameters. Using printf will get you at least three varieties of
escaping bugs, so you'll need special libraries to generate each
format.
I think form-encoding is OK if the WG knows that these response bodies
will never need to be complex, and never contain more than ASCII.
If these need more than ASCII, you'll be relying on everyone to use
the same (unspecified, btw) input encoding before they produce their
form-encoded string. You're still going to have to spec an encoding
param or make all implementations promise to use UTF-8 prior to URL
encoding. Neither of those strategies will work very well. That said,
the spec already has this problem elsewhere, so using JSON here won't
fix it entirely.
Also, adding something complex to a form-encoded response will get
pretty ugly, since you'll need a namespace-like thing prepended to
each field name.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
