cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@infoplanning.com>
Subject Re: [RT] redirection vs. aliases
Date Mon, 04 Dec 2000 14:28:59 GMT
----- Original Message ----- 
From: "Giacomo Pati" <giacomo@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Sunday, December 03, 2000 6:05 PM
Subject: Re: [RT] redirection vs. aliases


> Berin Loritsch wrote:
> > 
> > Thanks to my experience with trying to get C2 working with
> > WebSphere, and ColdFusion to work with Netscape Enterprise
> > Server, I have come to a very important realization.  No
> > vendor does redirection the same way (and some just do it
> > incorrectly).  A redirection is supposed to be a very simple
> > thing; however, it is causing me more problems than you
> > might imagine.
> > 
> > As an example, Apache httpd and Tomcat both perform redirects
> > as you might expect--it simply gives you the new page without
> > any funky HTTP status messages.  IBM has perverted Apache
> > with it's IBM HTTP Server (works with WebSphere), and Netscape
> > give a funny redirection HTTP response and most browsers can't
> > handle it.  Instead of the desired result (the new page),
> > it gives you "Page Unavailable" in IE or no result in Netscape 6.
> > 
> > Why is this an issue?  With ColdFusion, the only way to have
> > semi maintainable pages is to separate the logic sheets from
> > the display sheets and use redirection to get you to the next
> > stage.  My user state information gets lost if the server
> > screws up.  With Cocoon, I can use the sitemap to send me to
> > a default screen or even perform the same type of separation
> > with my XSP pages.
> > 
> > What I really want: an alias.  I am not trying to go to another
> > machine, or even another context.  I just want one page in place
> > of another.
> > 
> > How it would work: any time Cocoon intercepts a redirect() method
> > call, it processes the new URI in the same stream.  This has
> > the same effect, and you don't have Web server vendors screwing
> > you blind.
> > 
> > Do I sound like I am somewhere outside the loop, or is my frustration
> > shared?
> 
> No, it sounds reasonable and I think this was been discussed a real long
> time ago. The sitemap has the notion of two kinds of redirects:
> 
>   <map:redirect-to uri="..."/>
>   <map:redirect-to resource="..."/>
> 
> The first one issues a "normal" redirect using the Environments redirect
> service (because the sitemap engine has no idea of how to do it on its
> own). This can be any legal URL. The second form of redirect-to uses a
> defined <map:resource> to redirect to. What you want is something like:
> 
>   <map:redirect-to cocoon="..."/>
> 
> which should reinvoke the sitemap engine with a different requestURI,
> right? If this is the case we have to extend the Environment interface
> to let the sitemap notice the Environment to change the requestURI and
> reinvoke itself again?

Yes.  This is what I would like.  This would work wonders within the
framework of one Cocoon webapp.


Mime
View raw message