Well, no, jsonp is a special transport layer inside http. Making that fuzzy will cause (interop and security) problems.
On Tuesday, August 17, 2010, Luke Shepard <lshep...@facebook.com> wrote: > From the perspective of OAuth, a JSONP endpoint is just another protected > resource. I'd rather not need us to write an extension for every type of > protected resource we might need to access. > > I think the wordsmithing you discussed is what Paul's proposing - just saying > essentially "look, these are the HTTP error codes you can expect, but it's > okay for the server sometimes to give 200 on an error response anyway". That > would be necessary even if we wrote an extension. > > On Aug 17, 2010, at 12:43 AM, Torsten Lodderstedt wrote: > >> 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 -- -- John Panzer / Google jpan...@google.com / abstractioneer.org / @jpanzer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
