On Mon, Jun 25, 2001 at 10:42:48PM -0000, [EMAIL PROTECTED] wrote: > Mike Orr <[EMAIL PROTECTED]> wrote: > > > > [Cookieless sessions and the need for session identifiers] > > Of course, the restrictions are clear: any link not providing the information > contained within the form is going to result in a loss of state, but then a > framework which promotes this kind of state management could (and should) > provide the means to generate the links appropriately. Ideally, yes. The problem is, providing non-cookie and auto-switching support for server-side sessions turns out to be more difficult and insidious than it appears at first glance, because of all the site-internal links buried in the HTML text. HREFs are so ubiquidous that they become invisible, and the content manager forgets they need to be sessionized. It's so easy to write an '<A HREF="cross_reference.html">another section</A>'--oops, there goes my session data bye-bye! This could be addressed with an on-the-fly filter that sessionizes the page on the way out, but that's potentially slow and misparse-prone. Or if you're building the HTML from templates (a la CheetahTemplate, http://cheetahtemplate.org), the template framework could provide some convenient mechanism for marking all the links that need the session ID added if cookies are off. The question is, what would that "convenient mechanism" look like? The best way I've found is to treat them like ordinary plug-in variables, even if there are hundreds of them. This works but introduces an extra level of complexity when suddenly your number of plug-in variables triples. Given that, it's no wonder that many sites and applications just say, "Screw it, this site requires cookies." Because with cookies, you avoid the need for all this URL transformation. But that does a disservice to those who surf without cookies because of sites that misuse them to secretly build multi-company customer profiles. > Why should I, with my multitasking PC and > potentially disruptive office environment, which may demand my attention at > numerous unforeseen moments, have to sit down and reserve n minutes of > completely uninterrupted time to perform some task in a Web application, just > because of an artifact of the implementation mechanism? It seems so > unjustified, yet some attempts to book airline tickets and participate in > other online transactions seem to be curtailed by such demands. Becaues the server has no way of knowing whether you who pressed Submit are the same person who requested the page an hour ago. Perhaps it's a public-access terminal or a shared office computer. At some point, the server just has to guess and assume the transaction isn't authorized. Then there's the real issue of old sessions filling up memory or disk space. And the issue of programmers assuming that old sessions will fill up memory or disk space even if they don't. Of course, the programmer doesn't necessarily know beforehand how much traffic the site will generate, so s/he has to prepare for the worst. -- -Mike (Iron) Orr, [EMAIL PROTECTED] (if mail problems: [EMAIL PROTECTED]) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-discuss
