+1 On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote:
Hi Fellow OAuthers, If a resource wants to return data via the JSONP mechanism then it MUST return an HTTP 200 error code, or else the browser won't actually call the callback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on errors which won't ever tell the client that an error happens. For example: GET /me?callback=jsonp_cb HTTP/1.1 Host: graph.facebook.com<http://graph.facebook.com/> HTTP/1.1 200 OK Content-Type: text/javascript; charset=UTF-8 Content-Length: 152 jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query information about the current user." }); would never get sent to the browser if we obeyed the spec and sent it as an HTTP 400. --- So, I recommend we add wording to 5.2.1 like: If the protected resource is issuing a response that requires a different HTTP status code than the one specified (for example, JSONP), then it MAY use an alternate HTTP code. The server should make it clear which parameters trigger this mode so that clients know not to rely on the HTTP status code for error detection. Paul _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
