...and tunneling protocols over HTTP have worked *so* well in the past... *makes another drink to help forget the SOAP nightmares*
back to your regular programming... On 18/08/2010, at 9:06 AM, John Panzer wrote: > 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 -- Mark Nottingham http://www.mnot.net/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
