What conclusions would you draw from this internet-draft? Shall we move
for long polling and "Timeout" headers?
regards,
Torsten.
Am 09.06.2010 09:29, schrieb Manger, James H:
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
