Correct me if I'm wrong. Isn't the enable-ness of the URL rewrite the responsibility of the container, not Struts?
Recently, we had a project using Struts with Weblogic. Weblogic has an option in its proprietary weblogic.xml descriptor to turn off URL rewrite. We tried it and it worked. No more 'jsessionid' appeared on the URL. (We tried this because our client was worried that the app users would try to cut and paste the session id from one PC to another and compromise the security...) Then, shouldn't Tomcat provide the same option? -- John At 06:52 pm 23-12-2001 -0800, you wrote: >On Sun, 23 Dec 2001, Ted Husted wrote: > > > Date: Sun, 23 Dec 2001 06:57:35 -0500 > > From: Ted Husted <[EMAIL PROTECTED]> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: Forced URL rewriting > > > > There was a question on the list a while back regarding URL rewriting > > and clustered servers that I didn't have a good answer for. Basically, > > they want to avoid maintaining the session, apparently as a performance > > tweak. (What I don't know is whether that would actually make a > > difference in real life.) > > > > But, should the tags have an option to supress rewriting (and just > > lookup the path)? > > > > Ideally, you'd think this should fall on the container. The spec does > > require an option to disable cookies, but not so much url rewriting > > (when supported). You could turn this off in Resin, but apparently not > > in Tomcat, and who knows about the others? > > > > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg17727.html > > > >Sessions are NOT required by the servlet or JSP specifications -- to make >them go away in your application, you should simply don't create a session >(in your servlet), and every JSP page needs to start with: > > <%@ page session="false" %> > >in order to avoid the default JSP behavior of creating a session. > >If you are not in a session, URL rewriting won't change the argument -- it >will be returned unchanged (just as it is when you are in a session but >the container knows that you are using cookies). Providing a >configuration option to make the various Struts tags not call encodeURL() >would be technically feasible, but IMHO it would have a vanishingly small >impact on performance so I cannot see it being worth the bother. > >Whether omitting sessions entirely has a performance benefit is impossible >to generalize - it depends very much on how your application server >implements sessions, as well as what you store in them. You also have to >consider the extra cost of the alternatives you employ to deal with the >absence of sessions (such as extra hidden variables in your pages, and/or >storing user state information in a database or EJB). There is no general >rule on what's best. > >You should also note that some container features (such as form-based >login) require sessions to be useful. In addition, the following Struts >features cannot operate in the absence of sessions: >* Per-user localization (<bean:message> and friends) >* Transaction tokens to catch resubmits of the same form > because of the back arrow >* Maintaining form beans across multiple pages (without > having all of the properties represented as hidden properties > on every single page). > >My experience has been that the scalability issues people run into with >sessions are more related to keeping too many session attributes around >for too long, and not due to the existence of the session itself. In a >distributed environment, there is some amount of overhead (sessions will >need to be "sticky" to a particular server), but the tradeoffs for what >sessions buy you needs to be balanced against this cost. > > > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > > -- Custom Software ~ Technical Services. > > -- Tel +1 716 737-3463 > > -- http://www.husted.com/struts/ > > > >Craig McClanahan -- John Yu Scioworks Technologies e: [EMAIL PROTECTED] w: +(65) 873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 Scioworks Camino - "Rapid WebApp Assembly for Struts" -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
