The current richness of the problem reporting solution seems to blur the line between useful runtime information and general debugging tools. The only reason to provide error codes is to improve interoperability. I am not sure why a client would be sending duplicate oauth_ parameters to begin with other than a software bug. If the duplication isn't for an oauth_ parameter, it is not appropriate to handle it using an OAuth error code.
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of John Kristian > Sent: Friday, November 06, 2009 11:15 PM > To: OAuth > Subject: [oauth] Re: Problem Reporting Extension: Duplicate OAuth > Parameters > > > Could consumer software recognize oauth_problem=parameter_duplicated, > and react by sending another request without duplicate parameters, > without bothering the user? That would be good for the user, and thus > a good reason to add parameter_duplicated to the repertoire. But I > wonder why the consumer wouldn't send a correct request (without > duplicates) to begin with. > > Regarding encoding, an example response body would be > > oauth_problem=parameter_absent > &oauth_parameters_absent=oauth_token%26oauth_nonce > > ... but without the line break. The '&' that separates the absent > parameter names is percent-encoded to %26 (like any parameter value). > A consumer can parse this easily. > > On Nov 6, 10:03 am, Paul Walker <[email protected]> wrote: > > Um, the consumer would resolve the problem by not sending duplicate > > parameters. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
