struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Donnie Hale" <don...@haleonline.net>
Subject RE: Forced URL rewriting
Date Sat, 05 Jan 2002 02:04:36 GMT
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:craigmcc@apache.org]
> 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 <donnie@haleonline.net>
> > Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> > To: Struts Developers List <struts-dev@jakarta.apache.org>
> > 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:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message