Good point. The server will have to provide special JSONP support anyway. This is the only place where the requested status code handling is needed.
+1 for a JSONP extension spec This might also result in much cleaner JSONP support. regards, Torsten. Am 17.08.2010 um 09:28 schrieb John Panzer <jpan...@google.com>: > Except you cannot guarantee that result of course (proxies, apache > plus tomcat separate processes etc. will all result in error codes). > > Doesn't this all depend on a jsonp extension in the first place - the > client has to request a special jsonp response by specifying the > callback, thus making the server both use 200s where possible and also > wrap its response data in a callback call? That's not part of the > spec either, why not just define both pieces of behavior in a jsonp > extension spec? (Assuming this can be done without violating the > letter of the core spec, which might take some wordsmithing.) > > On Monday, August 16, 2010, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: >> Paul Tarjan schrieb: >> >> 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. >> >> >> I think this can be achieved in two ways: (a) either the client tells the >> server using a parameter or (b) the server always responds with status code >> 200 in some cases. From my understanding, status code 200 is relevant for >> requests following the rules of section 5.1.2 only. So my sugesstion would >> be to go with option (b) and modify the spec to always return status code >> 200 for such requests. This keeps the spec simpler and preserves the >> behavior of requests following the rules of section 5.1.1.. >> >> regards, >> Torsten. >> >> >> 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 >> >> >> >> >> >> >> > > -- > -- > John Panzer / Google > jpan...@google.com / abstractioneer.org / @jpanzer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
