On Wed, Jun 9, 2010 at 12:17 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote:
> 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 the server" > 2) Do HTTP clients supports the Retry-After header? > Both good question. It's probably fair to say that the original intention for 503 did not include telling clients that the resource they're requesting isn't quite ready yet. On the other hand, the original "overloading" language does suggest that it's perfectly within the intentions of the founding fathers to throttle clients if they become too pesky. Which is what we're trying to do here: As far as OAuth is concerned, the client could just sit there and loop and keep asking the server every 2 milliseconds. We thought that wasn't a good idea because (among other things) that might *overload* the server, not because OAuth wouldn't work if the clients did that. So a 503 seems like a reasonable response there, especially since it has that Retry-After header, which indicates that the original intent of a 503 at least included the case where the inability-to-serve was due to the fact that he clients were coming in too fast. As for library support for this - I'm not sure. I briefly looked at the Apache commons client and couldn't find a, say, simple flag that would enable some retry mechanism based on 503s and retry-after headers. Maybe I didn't look hard enough. But it should be fairly easy to add supprot for this to any HTTP client library, right? Dirk. > regards, > Torsten. > > 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 listoa...@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
