using mechanisms provided by the HTTP protocol sound reasonable to me.
I see two questions:
1) Is 503 intended for that purpose?
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says: "The server
is currently unable to handle the request due to a temporary overloading
or maintenance of the server"
2) Do HTTP clients supports the Retry-After header?
regards,
Torsten.
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
