On Tue, Jul 13, 2010 at 11:17 AM, Brian Eaton <[email protected]> wrote:
> On Tue, Jul 13, 2010 at 9:42 AM, David Recordon <[email protected]> > wrote: > >> That strikes me as very odd - returning some params in the query, and > >> others in the fragment is just weird. > > > > I actually think that you want this – albiet odd – combination when > > requesting both a code and token. The code and state parameters are > needed > > by the server and thus are query parameters. The access token, scope, and > > expires in shouldn't be sent to the server via HTTP and thus are within > > the fragment for the JavaScript to access. > > The problem is that if you do it this way you end up busting the > browser cache. All of the performance improvements offered by the > user-agent profile are lost. > This is one of the key reasons imho. JavaScript can access the query and the fragment, so it would technically work in either case. But having the flexibility to choose where it goes saves on one round trip to the client application. For instance, in the Facebook SDK we would like to do this background ping, and save the code in a cookie and fire a JavaScript callback to let the client application know that one is available. The client application can then decide if it wants to trigger a network request to send the code to it's servers, or not. By allowing this data to come in the fragment, we can use a static endpoint (potentially served from a subdomain that goes to a CDN) and reduce the process to a single server request in the common case. -Naitik
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
