Ah, ok. I disagree with this as blanket recommendation though it can make sense in some cases.
Agreed that OAuth is more of a plug-in for HTTP than a separate protocol layered on top. On Tue, Mar 23, 2010 at 10:09 AM, Richard Barnes <[email protected]> wrote: > Well, the relevant part says "200 or 500"; the basic message is that if > your HTTP-using application has an error, but the HTTP was OK, then you > shouldn't have an HTTP-layer error. So for instance, in the GEOPRIV HELD > protocol [1], every request returns 200 unless the HTTP is screwed up, and > there's an <errorResponse> element that provides application-layer codes and > explanations. > > Again, this model might not make sense for OAuth, since OAuth is more tied > into the HTTP layer than layered on top of it. You could probably make a > case for using 401/403 in this space, and maybe for some new codes. > > --Richard > > [1] http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery > > > > > > On Mar 23, 2010, at 9:54 AM, John Panzer wrote: > > That's an interesting and informative RFC, but it recommends using the 500 >> response code for all errors (unless I'm misreading). Errors due to >> incorrect input should be 4xx. >> >> On Mon, Mar 22, 2010 at 10:02 PM, Richard Barnes <[email protected]> wrote: >> In case it's helpful, BCP 56 / RFC 3205 provides recommendations for using >> HTTP as a substrate for other protocols: >> >> <https://tools.ietf.org/html/bcp56> >> ... in particular with respect to status codes: >> >> <https://tools.ietf.org/html/bcp56#section-8> >> >> It's worth thinking about how that document applies to OAuth, since the >> goal here isn't really necessariliy to use HTTP as a substrate, but rather >> to extend HTTP in certain ways. >> >> --Richard >> >> >> >> >> On Mar 22, 2010, at 10:56 AM, David Recordon wrote: >> >> In drafting OAuth 2.0 I removed a lot of the error codes throughout >> the flows and in this draft encouraged people to use HTTP status codes >> (like 1.0a does). I've heard the feedback from multiple people that >> they'd like more specific error codes than what can be expressed in >> HTTP. I'd like to use this thread – or ideally a wiki page that >> someone creates – to build consensus around the error codes needed >> throughout protocol responses. >> >> Is someone willing to take the lead on this? http://wiki.oauth.net/ >> should be easy enough to create a new page on. >> >> Thanks, >> --David >> _______________________________________________ >> 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
