using mechanisms provided by the HTTP protocol sound reasonable to me.
I see two questions:
1) Is 503 intended for that purpose?
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says: The server
is currently unable to handle the request due to a temporary overloading
or maintenance of
Right on cue a new internet-draft covering the HTTP polling issue has just
appeared:
Hypertext Transfer Protocol (HTTP)
Timeoutshttp://tools.ietf.org/html/draft-loreto-http-timeout
draft-loreto-http-timeout [June 2010]
See also:
Best Practices for the Use of Long Polling and
be used, with a (informative) reference to those 2
drafts, would be a decent solution for OAuth2.
--
James Manger
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, 9 June 2010 5:59 PM
To: Manger, James H
Cc: Dirk Balfanz; OAuth WG
Subject: Re: [OAUTH-WG] polling
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
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
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 balf...@google.com
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
