I disagree. The sole purpose of the specification is to achieve interop. By creating this exception for JSONP calls, you are breaking interop with non JSONP clients. For this to work, you need to specify exactly when this exception happens, and how to deliver the HTTP status code to the client. This sounds like a specification. For example, how is the client going to get the original HTTP status code?
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). If JSONP is an important use case, 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 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. As for the argument that developers are not going to read so many specification, so core should address it - that's also silly. Most developers are never going to read the specification. At best, they will read the vendor API docs. For the record, I have no objection to the core specification fully addressing the JSONP use case. But I'm opposed to making such an underspecified exception. EHL From: 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 https://www.ietf.org/mailman/listinfo/oauth
