> What conclusions would you draw from this internet-draft?

> Shall we move for long polling and "Timeout" headers?



I have not been following the polling issue deeply, but I agree with Dirk that 
OAuth2 should try leave the polling issue to other specs as much as possible.

Suggesting long polling be used, with a (informative) reference to those 2 
drafts, would be a decent solution for OAuth2.



--

James Manger



From: Torsten Lodderstedt [mailto:[email protected]]
Sent: Wednesday, 9 June 2010 5:59 PM
To: Manger, James H
Cc: Dirk Balfanz; OAuth WG
Subject: Re: [OAUTH-WG] polling in the device flow



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

Reply via email to