On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer <jric...@mitre.org> wrote: >> > OAuth tokens as a form-encoded element in a post body? Yes. Keep it. >> >> Just curious. What use case would require that the access token is put >> in the post body as opposed to an http header when accessing a >> protected resource? > > If nothing else, it parallels the use case of a GET-style query > parameter. It makes sense to have it be valid in both ways to allow > developers to put the token in with whatever other parameters they're > passing along. I've got plenty of use cases here for the query > parameters: it's needed for cases where your client can't get any deeper > into HTTP than "hey go fetch me this URL".
You can still use query parameters with POST. > What use case says we shouldn't do POST parameters like that? A server > wanting to do early-dispatch of a request was brought up, but that was > only in the case of handling OAuth 1 and 2 simultaneously as I > understood it. If a server's going to be doing dispatch on auth headers > and query parameters already, it seems that it's got the wherewithal to > parse a form-encoded body, too. Parsing the body is not trivial. Some filters do not have access to it (apache mod_redirect for example), some frameworks will allow you to access it once and then commit to a format, a decision that cannot be made by a filter (in Java see ServletRequest: getInputStream vs getReader vs getParameter). Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
