Sure - as long as this is tied to the very special case of a tunneled protocol over http.
On Tuesday, August 17, 2010, David Recordon <record...@gmail.com> wrote: > Luke's point still holds true of the core spec needing to allow a 200 status > code on an error in this scenario. I'd also rather see this as part of the > core spec as it reduces the number of things that implementors will need to > read for common use cases. > > --David > > On Tue, Aug 17, 2010 at 9:06 AM, John Panzer <jpan...@google.com> wrote: > > 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-- > -- > John Panzer / Google > jpan...@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > 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
