From bloritsch@infoplanning.com Mon Dec 4 14:30:45 2000 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 65861 invoked from network); 4 Dec 2000 14:30:45 -0000 Received: from fw.infoplanning.net (HELO infoplanning.com) (@209.8.58.131) by locus.apache.org with SMTP; 4 Dec 2000 14:30:45 -0000 Received: (qmail 17552 invoked from network); 4 Dec 2000 14:35:46 -0000 Received: from unknown (HELO johnnybravo) (192.168.0.189) by inet with SMTP; 4 Dec 2000 14:35:46 -0000 Message-ID: <013a01c05dfe$8ae120a0$bd00a8c0@infoplanning.com> From: "Berin Loritsch" To: References: <004201c05bf1$42429680$bd00a8c0@infoplanning.com> <3A2AD1C3.21852FFE@apache.org> Subject: Re: [RT] redirection vs. aliases Date: Mon, 4 Dec 2000 09:28:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Giacomo Pati" To: 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: > > > > > 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 to redirect to. What you want is something like: > > > > 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.