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
