Another alternative idea -- designate the 'format' param as an accept-header override. This technique has been successful for the X-Method-Override header and cements the Accept header syntax as the proper mechanism for selecting output format.
On Thu, Jun 10, 2010 at 10:59 AM, Justin Richer <[email protected]> wrote: > One of the things that I found particularly useful with working with > OAuth1 was the ability to perform an entire transaction through URL > parameter manipulation. This is why I wholly support keeping the client > id and secret fields in the client auth flow and the username and > password fields in the username flow. I'm fine with supporting > alternative ways to pass information around, with various headers or > basic auth or what have you, but I don't want to lose the ability to GET > and/or POST a bunch of form parameters to use OAuth. I don't want to > have to dive any deeper into the HTTP stack than that. > > With that in mind, I support keeping the format parameter, with an > alternative expression of the same information being made available via > the Accepts header for clients that want to do that instead. > > -- Justin > > On Thu, 2010-06-10 at 13:51 -0400, Marius Scurtescu wrote: > > I am implementing an OAuth 2 library and the format parameter does not > > feel right. > > > > If a client is using a library then the response format should be > > totally transparent to the client. The library may have a setting if > > the client wants to force a format for whatever reason, but individual > > messages that the client builds and receives should not care about the > > format. > > > > I think initially the Accept header was used. All current "format" > > uses are in direct requests, so Accept could be used. > > > > To give a counter example, the User-Agent flow does not use "format" > > and it always returns form-encoded in the fragment. There where > > discussions to use JSON for this flow as well. Should we do that? If > > yes, do we need "format"? Accept does not work in this case. > > > > I don't have a good suggestions, just wondering if anyone else run > > into this issue. > > > > Marius > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
