While I think about it, it may also be desirable in some situations to keep the session information, even when redirecting to another scheme. For example, some hybrid technology sites may use centralized session information and may implement single sign-on between technologies. I have been involved in such a project myself, where a Transact server was sitting as an interim - authorized by a PHP application. The session id was carried through from the frontend (php) to the back-frontend (transact).
I'll just clarify my point below too - in this case, the redirect would still work, albeit relative, but if we are to strip session information for schemes, then the session id would be lost in the redirect (without cookies). > -----Original Message----- > From: Cliff Rowley [mailto:cliff@;onsea.net] > Sent: 18 October 2002 17:12 > To: 'Struts Developers List' > Subject: RE: Going to other context and/or server in 1.1 > > > My knowledge is weak in this area, but is a :// sequence > required to be escaped? If not, the the following situation > could occur when looking for :// blindly - I'll use a search > engine as an example: > > ActionForward -> redirect to /search.do?query=:// > > In this case, blindly looking for :// would be bad. It would > be better, in my humble opinion, to quote the URL > specification directly and require <scheme>://<rest of url>. > > Again, disclaimer :) > > > -----Original Message----- > > From: Eddie Bush [mailto:ekbush@;swbell.net] > > Sent: 18 October 2002 17:10 > > To: Struts Developers List > > Subject: Re: Going to other context and/or server in 1.1 > > > > > > At the risk of entertaining the masses, I think I'll comment > > that I like > > that idea. I'll try to get a fix in by this evening. If > > someone thinks > > that is bad, speak now or forever hold your peas! > > > > David Graham wrote: > > > > > What if we looked for "://" instead of specific protocols? > > > > > > We could also add an attribute like contextRelative="false". > > > > > > David > > > > > > -- > > Eddie Bush > > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:struts-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:struts-dev-help@;jakarta.apache.org> > > > > > > --- > > Incoming mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002 > > > > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002 > > > > -- > To unsubscribe, e-mail: > <mailto:struts-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:struts-dev-help@;jakarta.apache.org> > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002 -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
