Re: [OAUTH-WG] polling in the device flow

On Wed, Jun 9, 2010 at 10:58 AM, David Recordon <recordond@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.Manger@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
> >
> >
>