On Aug 7, 11:52 pm, Jeff Chimene <[email protected]> wrote: > 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: > > > 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?
Yes it is. Hence my question. We could perform authentication through an iframe with a different URL on the server that is in sub- path of the server root. However, GWT doesn't explicitly support this. Against, hence my question. Can a single GWT application be somehow explicitly (through annotations?) split across a URL space? > > 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. On authentication, we re-stuff the client state. If the client has cleared their cookies, they will get re-built on login. Again, this is something that only needs to occur on first hit to the site. The application reads these cookies on the client-side, but as stated we don't want them blasted back to us on every request. Again pointing to the need for any site that maintains a fair amount of client state in cookies to be able to split an application across a URL space. > > 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. There is a solution that is supported very clearly by HTTP and the Cookie specification -- the cookie path. This entire post is about how because GWT does not (seem) to allow splitting an application across a URL space, no GWT application can properly take advantage of the path portion of the cookie specification. Every cookie from a GWT application by definition will come from the root URL of that application and therefore will be sent back with every RPC by that application. If for example, GWT generated a hidden iframe for each RPC service interface and the code associated with that RPC loaded from a unique URL space, specified by the user, for example 'login service' code loaded from /login, 'mail service' loaded from /mail, etc., then cookies returned by the login service with path /login would only be resent in requests to the login service and never to the mail service. Of course the user has control (on the server-side) of the path created for cookies -- I could create a cookie in the root of the server that of course would be resent on all RPC requests. But as it stands, there is no knob to turn or lever to pull to control the URL space for cookies effectively within GWT. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
