Hi Bill, * Bill Moseley <[EMAIL PROTECTED]> [2007-07-29 00:05]: > On Sat, Jul 28, 2007 at 11:21:56PM +0200, A. Pagaltzis wrote: > >> User visits page A. > >> User visits page B in another tab. > >> User submits form A. > >> User submits form B. > >> A updates the flash. > >> B updates the flash. > >> Page A2 loads with whatever flash won. > >> Page B2 loads with whatever flash won. > > > >Keeping implicit state on the server blows. News at 11. > > > >(The right way: don’t use flash. Put the stuff somewhere where > >you can give it a URI and send the user to that address.) > > So simple case: client posts which updates a user "Foo". You > redirect after post and want to display 'User "Foo" was > updated' (or something you need to store server-side between > the post and the redirect).
Exactly. > What's your approach? Always pass around a session id in the > URL? On redirects pass an unique id to get at that > request-specific message? The latter – or neither. If it’s just to show the user a canned message, I’d probably add a query parameter to the URI and be done with it. For any small predetermined data set (eg. a handful of flags), I’d simply encode the state right into the URI. Putting a unique ID in the URI is the right approach for anything that you actually need to store on the server somewhere – eg. for multi-page forms. The only use I have for the session ID is as an auth token (and then only because HTTP auth is *still* broken in browsers… argh! sigh). I never store anything but credentials in the session. A point regarding the URIs constructed by the server: I’d usually include a timestamp-ish token and a hash value in the URI. The hash is taken over the unique ID or query params or whatever other state data is there, plus the timestamp, plus a server-side secret. The secret ensures that this hash can only be generated correctly by the server, so the authenticity of a URI can be verified. The timestamp, verified by the hash, allows any expiry testing to happen by just looking at the URI, without ever hitting the database (or other session storage backend) at all. It has to be mentioned that the resulting URIs aren’t exactly pretty. (A 128-bit hash takes 22 digits to encode in base 64 (10 digits + 26 uppercase letters + 26 lowercase + underscore + hyphen = 64 symbols). That’s not a _huge_ amount of cruft, fortunately, but enough to irritate a bit. However that should be irrelevant if you use clean URIs for any pages that represent non-ephemeral things (as well you should). > If so, how do you manage orphans, say if the redirect never > happens? How do you manage orphaned sessions? :-) With all approaches, there is transient state on the server that needs to be managed as such, so implementation-wise there isn’t much discrepancy. The difference is only in whether that state is addressable. When it is, the application fits better into HTTP and you get to do things like end the request cycle with a 301 or 410 before you do any I/O at all. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/