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

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
<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
>
>