Right on cue a new internet-draft covering the HTTP polling issue has just appeared:
Hypertext Transfer Protocol (HTTP) Timeouts<http://tools.ietf.org/html/draft-loreto-http-timeout> draft-loreto-http-timeout [June 2010] See also: Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP<http://tools.ietf.org/html/draft-loreto-http-bidirectional> draft-loreto-http-bidirectional [Feb 2010] -- James Manger Am 08.06.2010 22:23, schrieb Dirk Balfanz: Hi guys, currently, we specify how polling should work in the device flow as part of the OAuth2 spec. I would argue that that polling should be handled at a lower layer of the stack, and that OAuth2 should be silent on the issue of polling. The benefit will be a simpler spec. HTTP specifies the 503 response code with the (optional) Retry-After response header. ASs could just use that mechanism to throttle clients, instead of handling it at the OAuth layer. The OAuth spec could say something like: "The client requests the access token after the user approves or rejects authorization. If the client cannot determine when the user has approved or rejected the authorization, the client MAY poll the server. The server MAY use throttling mechanisms such as 503 HTTP response codes and Retry-After response headers which, if used, the client MUST obey." What do you guys think? BTW, there is some precedence for this. Google's APIs use 503 response codes to throttle servers, e.g. http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html Dirk.
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
