I think long polling came up at the face to face and we decided to not fundamentally change how the flow works until we have implementation experience.
I'm fine with using 503 since it's not really a fundamental change. --David On Wed, Jun 9, 2010 at 4:51 PM, Dirk Balfanz <[email protected]> wrote: > On Wed, Jun 9, 2010 at 10:58 AM, David Recordon <[email protected]> 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 >> <[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
