From: Luke Shepard [mailto:lshep...@facebook.com] Sent: Wednesday, August 18, 2010 12:12 AM To: Eran Hammer-Lahav Cc: Paul Tarjan; OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP
For example, how is the client going to get the original HTTP status code? Why does the client need the HTTP status code? It seems like the real data is the OAuth error code (i.e., "invalid request"). The HTTP status code is just gravy so that we're consistent with HTTP. This is not a legal document, and you are free to implemented it differently if you do it in a way that does not harm interop. In this case, you are basically proposing changing a MUST to a SHOULD, which takes away any interop value the requirement has in the first place (ie. being predictable and consistent). Okay ... so why are we specifying HTTP codes at all then? Since we have clearly defined the error types, why is it wrong to say "use whatever HTTP code you think is right, here are some suggestions"? There is nothing wrong with saying that, if we decide that there is no interop value in specifying them. Pointing to the HTTP spec and say follow that is perfectly fine. But as currently written, since the codes are prescribed, clients are allowed to rely on them, which will lead to problems. EHL If JSONP is an important use case It is. and if it should be consistently implemented across services, then it needs to be specified and such a specification can clear override the core specification directive on HTTP status code. I dunno, JSONP is pretty commonly implemented across lots of services today. You typically pass in the parameter "callback" and then that prepends your response. I'm not aware of a specification for it, but convention + copying each other has made services somewhat consistent in this. In any case, I don't think this group should be held up by writing a new spec just to address this one use case. I don't know where people got the idea that other specifications cannot modify requirements in the core specification - that's just silly. As long as you spell it out and provide enough detail to maintain interop with the new work, it is perfectly fine. This is not the constitution. (The Constitution allows amendments, too - but similarly, it's a lot of work) From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org] On Behalf Of Paul Tarjan Sent: Friday, August 13, 2010 2:31 PM To: OAuth WG Subject: [OAUTH-WG] Returning HTTP 200 on Error for JSONP 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 OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
