Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP

[Torsten Lodderstedt <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>    
>>>>         
>>>  
>>>       
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>     
>
>