On Wed, Jun 9, 2010 at 10:58 AM, David Recordon <record...@gmail.com> wrote:
> Unless I'm misreading the Timeouts spec, it defines a HTTP request > header which the client uses to tell the server how long it will wait. > That's how I read them, too. But that might be an alternative way to pick up the token in the device flow - issue a "hanging" request that returns when the token is rejected/approved. If you do that, then the timeout specs become relevant. Either way, it feels to me like this should be handled at the HTTP layer. Dirk. > That's a different problem from the server telling the client to back > off it's request rate. > > A 503 with a Retry-After header seems reasonable. We should specify > this interaction given that 503 headers will be new to many > developers. > > --David > > > On Wed, Jun 9, 2010 at 12:29 AM, Manger, James H > <james.h.man...@team.telstra.com> wrote: > > Right on cue a new internet-draft covering the HTTP polling issue has > just > > appeared: > > > > > > > > Hypertext Transfer Protocol (HTTP) Timeouts > > > > draft-loreto-http-timeout [June 2010] > > > > > > > > See also: > > > > Best Practices for the Use of Long Polling and Streaming in > Bidirectional > > HTTP > > > > 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
