Well, I'll take a stab at this so that this email doesn't disappear into the void. I think these are good design questions.
On Tue, Aug 4, 2009 at 10:55 PM, brett.wooldridge<[email protected]> wrote: > > I have a question about cookies and maintaining client-side state, and > looking for suggestions about how to solve (what I perceive to be) an > issue (for us). > > We allow the user to create a "sticky" login. You know, the one where > they tick the checkbox that says something like "Stay logged in?" > This of course creates a persistent authentication token (cookie) on > the client. Really we only need this cookie on the first "hit" from > the client -- we re-authenticate then send back (via RPC) a session > identifier that is used in all further conversations with the server. OK. > What we would like to avoid, but seems unavoidable (hence this post), > is having the cookie sent with every request to the site. Because the > entire site, from the front page all the way back is one entire GWT > application, the "path" (in cookie terms) is always the root of our > server. Therefore, the cookie gets sent with every RPC to every > service. Isn't this part of the HTTP protocol? > We would like to stuff additional persistent information down to the > client for survivability across visits, such as user preferences, but > we don't want this stuff blasted back to us with every request. How can you ensure real survivability across sessions w/o storing preferences on the server? Preferences are lost once the client clears cookies. Storing preferences via cookies is a brittle technique, esp. if it takes significant time to reestablish those preferences after clearing cookies. > For > the purpose of envisioning our traffic patterns, imagine our site is > an online game (it's not, but...) with a single client making one call > every second or three and 10k+ simultaneous users. Right now the > typical "payload" is only two or three dozen bytes, but the size of > the cookie even though small is actually larger. We could cut our > traffic in half without the cookie being sent back on every request. OK, but you'll have to stop using HTTP. > Is there an effective way to break up an single application across a > URL space? Maybe via multiple modules? For example, can we serve the > 'login' module .js files from <domain>/login and the 'settings' > module .js files from <domain>settings? If so, does that mean that > from GWT I can access cookies in the path '/login'? My concern is > that because the "page" was served from "<domain>/", even though the > script was served from "<domain>/login" that those cookies will not be > accessible. As it is, if the server sends back a cookie with a path "/ > login", they are not accessible to the client. I was surprised, > though maybe shouldn't be, as I expected JavaScript served by a > certain domain to be able to access ALL cookies in that domain, > regardless of path. That seems not to be the case. It's not clear from the description that the use of the cookie domain and path attributes in the example are correct and complete. Part of the issue may be that your server isn't RFC 2109 compliant. You might also want RFC 2965 cookie management To reiterate, I'm not convinced that saving preferences in a cookie is a good idea. It does make more work for you in the sense that you would replace the simplicity of cookies w/ the complexity of database maintenance. It may be that you've already evaluated this tradeoff. Another possibility may be to use some of the backing storage solutiions available to Javascript: the secondary storage subsystem of HTML 5; backing storage using Flash; and (of course) Gears. I hope this was some help. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
