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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > [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 > > > > > > > -- -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
