It not being a spec issue anymore is the point I was trying to make. I agree with you that using security as the reason is a little silly. However, from the standpoint of bookmarking and corporate intranet apps and their corresponding help desk support issues, I can see requiring cookies and disallowing URL rewriting at the app level. Note that the original poster mentioned that the weblogic setting is in the "weblogic.xml" file. That file, in case you're not aware, is a WebLogic-proprietary deployment descriptor file for a web application that goes in the WEB-INF directory along with web.xml. So, in the same container VM, one web app could have URL rewriting on and another have it off.
Donnie > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 04, 2002 8:34 PM > To: Struts Developers List > Subject: RE: Forced URL rewriting > > > > > On Fri, 4 Jan 2002, Donnie Hale wrote: > > > Date: Fri, 4 Jan 2002 19:49:30 -0500 > > From: Donnie Hale <[EMAIL PROTECTED]> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > > To: Struts Developers List <[EMAIL PROTECTED]> > > Subject: RE: Forced URL rewriting > > > > Craig, > > > > I think the point is that WebLogic meets the spec criteria but, for the > > application in question it was decided to turn off cookie-less > support via > > URL rewriting. Thus users of the application must have cookies > enabled. That > > doesn't reflect at all on the container's spec compliance, just > the choice > > of that particular app development team. > > > > And, of course, it *would* be legal for an *application* to not support > URL rewriting -- which is why it's perfectly legitimate to consider such a > switch on Struts itself. Even for that purpose, though, I'm inclined > against it -- the reason from the original proposer (security concerns) is > not persuasive to me -- but it's not a spec issue any more. > > > Perhaps obvious... > > > > Donnie > > > > Craig > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
