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"? 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
