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 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
