Yes, I'm talking about 5.2.1 For JSONP the user's browser is the client. It will make a request by executing some HTML like this:
<script src="http://graph.facebook.com/me?access_token=...&callback=jsonp_cb";></script> <script> function jsonp_cb(response) { if (response.error) { // error out return; } // do cool things } </script> (this is done instead of an AJAX request, because of cross-domain restrictions). As to Aaron's point, Google sends 3 parameters to the callback function, which I kind of like since the user can choose to get the code or not. Something like: jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query information about the current user." }. 400, 'Bad Request'); which you can grab with function jsonp_cb(response, code, status) { } or ignore it with function jsonp_cb(response) { } But all of this is outside of the spec. I just want to make sure the spec says that the HTTP status code can send as 200 if the server+client need it for errors. Paul On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote: > I would like to furthermore track down the relevant use cases. Assuming you > are referring to section 5.2.1, how does your client send the access token to > the resource server? I'm asking because I think error handling for URI query > parameters, Body parameters and Authorization headers could be handled > differently. For URI query parameters and Body parameters, returning the > error code in the payload instead of the status code would be acceptable from > my point of view since authentication is also pushed to the application > level. In contrast when using HTTP authentication, 40(x) status codes > together with WWW-Authenticate are a must have. > > Would such a differentiation help you? > > regards, > Torsten. > > John Panzer schrieb: >> Is there ever a case other than jsonp where this is necessary? >> >> On Monday, August 16, 2010, Aaron Parecki <aa...@parecki.com> wrote: >> >>> Excellent point. Would it be worth it to include a new error_code >>> parameter in the JSON response so that clients have a way to get the >>> http status code from the data available in the jsonp response? >>> >>> The response in this case might look like this >>> jsonp_cb({ >>> "error_code": 400, >>> "error": "invalid_request", >>> "error_description": "An active access token must be used to query >>> information about the current user." >>> }); >>> >>> Aaron >>> >>> >>> On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard <lshep...@facebook.com> >>> wrote: >>> >>> >>> +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 >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
