The question is though: <cringe/> How would I implement such a change? I'd have to change:
- the DTD
- the ActionConfig/ForwardConfig classes
- refactor all places requests are finally redirected/forwarded
Missing anything? I have *no* clue about the DTD - but I'm willing to learn ...
Cliff Rowley wrote:
Agreed, it would be the most flexible solution overall - allowing the developer to programatically choose whether it's on or off.Not that my opinion really counts :)-----Original Message-----
From: Eddie Bush [mailto:ekbush@;swbell.net] Sent: 18 October 2002 18:33
To: Struts Developers List
Subject: Re: Going to other context and/or server in 1.1
+1 - that would simplify things a great deal.
My idea was to have a static protocol list we'd iterate over - but I like yours much better.
Craig R. McClanahan wrote:
cases whenOn Fri, 18 Oct 2002, David Graham wrote:Date: Fri, 18 Oct 2002 09:29:04 -0600
From: David Graham <[EMAIL PROTECTED]>
Reply-To: Struts Developers List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Going to other context and/or server in 1.1
I thought of the http:// matching as well. Are there any
this logic wouldn't work? Hardcoding the protocol may be a
bad idea.Failure case: https://www.mysecuresite.comtherefore
Maybe we need an "absolute" attribute on ForwardConfig (and
ActinForward)?
-- Eddie Bush -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>