Bernhard, Does it really matter? In most Java application servers, don't they do both for the first request but after the second request, where cookies are detected to be on, they stop using url rewriting. Or do those first two communications scare you? ;) Besides, a packet sniffer could see the cookie being transmitted every time anyway so does it really matter if the cookie is in the browser URL line or being transmitted before the URL in the cookie header value for the HTTP request call?
Regards, David -----Original Message----- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 3:26 AM To: 'Struts Users Mailing List' Subject: AW: Forcing URL Rewriting over Cookies in an existing application. > -----Ursprüngliche Nachricht----- > Von: David G. Friedman [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 23. Januar 2006 18:10 > > What do you mean by "do it the other way around" ? > Well I mean that you ONLY use cookies for the session management and not URL Rewriting, you might want to do that for security reason, because when using URL Rewriting the Session ID is in the address line and the cache, so a pssoble security risk. I think this should be contollable in a standard way and not container-specific. Bernhard > > -----Original Message----- > From: Bernhard Slominski [mailto:[EMAIL PROTECTED] > Sent: Monday, January 23, 2006 11:34 AM > To: 'Struts Users Mailing List' > Subject: AW: Forcing URL Rewriting over Cookies in an existing > application. > > > Thank you! > But it's not possible to do it the other way round in Tomcat right ? > Also I think this should belong in the web.xml and shouldn't be > container-specific, what do you think? > > Bernhard > > > -----Ursprüngliche Nachricht----- > > Von: David G. Friedman [mailto:[EMAIL PROTECTED] > > Gesendet: Montag, 23. Januar 2006 17:28 > > An: Struts Users Mailing List > > Betreff: RE: Forcing URL Rewriting over Cookies in an existing > > application. > > > > > > The same thing (disable cookies but enable url rewriting) > > should work on Tomcat 4.X and 5.X. See the "cookies" > > attribute in the below url(s): > > > > http://tomcat.apache.org/tomcat-4.0-doc/config/context.html > > http://tomcat.apache.org/tomcat-5.0-doc/config/context.html > > http://tomcat.apache.org/tomcat-5.5-doc/config/context.html > > > > Regards, > > David > > > > -----Original Message----- > > From: Bernhard Slominski [mailto:[EMAIL PROTECTED] > > Sent: Monday, January 23, 2006 11:20 AM > > To: 'Struts Users Mailing List' > > Subject: AW: Forcing URL Rewriting over Cookies in an existing > > application. > > > > > > OT, but I'm interested, is this available im Tomcat too? > > > > Thanks > > > > Bernhard > > > > > -----Ursprüngliche Nachricht----- > > > Von: David G. Friedman [mailto:[EMAIL PROTECTED] > > > Gesendet: Montag, 23. Januar 2006 17:08 > > > An: Struts Users Mailing List > > > Betreff: RE: Forcing URL Rewriting over Cookies in an existing > > > application. > > > > > > > > > http://access1.sun.com/techarticles/sessions.iws.html > > > > > > Regards, > > > David > > > > > > -----Original Message----- > > > From: Jay [mailto:[EMAIL PROTECTED] > > > Sent: Monday, January 23, 2006 10:53 AM > > > To: user@struts.apache.org > > > Subject: Forcing URL Rewriting over Cookies in an existing > > > application. > > > > > > > > > Hi all, I have an application (Sun ONE 6.1 sp2, Struts 1.02 > > > (I guess)) that uses Cookies for session handling and has > > > been so for around 3/4 years. I have a requirement where I > > > want to force URL Rewriting even if the browser supports > > > cookies. Please help! Jay > > > > > > > > > Broadband interface (RIA) + mail box saftey = > > > http://Struts_User_List.roomity.com > > > *Your* clubs, no sign up to read, ad supported; try broadband > > > internet. > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
