I would blame the EnvironmentWrapper for ignoring its prefix property ("test/") when its redirectURL property is set to "B"... ?
Laurent ________________________________________ From: Cédric Damioli [mailto:cedric.dami...@anyware-services.com] Sent: lundi, 4. octobre 2010 19:49 To: dev@cocoon.apache.org Subject: Re: [2.1.11] Strange behaviour with a cocoon://, mount and redirect combination Yes. The SitemapSource is executed within the root sitemap, so the redirection leads to an error. Cédric Le 04/10/2010 18:58, Laurent Medioni a écrit : Hi, " but if I call http://server/test2/A, it redirects internally to cocoon:/B (ignoring the mount), thus leading to a 404 Not Found." Do you mean it is trying to match cocoon:/B in the root sitemap ? Laurent -----Original Message----- From: Cédric Damioli [mailto:cedric.dami...@anyware-services.com] Sent: samedi, 2. octobre 2010 17:04 To: dev@cocoon.apache.org Subject: [2.1.11] Strange behaviour with a cocoon://, mount and redirect combination Hi team, Before filling an JIRA issue, I wanted to know if the following use case is actually a bug or a feature (Cocoon 2.1.11): I have two sitemaps: In the root sitemap, I write two pipelines: <map:match pattern="test/**"> <map:mount src="sub/sitemap.xmap" uri-prefix="test" /> </map:match> <map:match pattern="test2/**"> <map:generate src="cocoon://test/{1}" /> <map:serialize/> </map:match> In the sub sitemap, I have: <map:match pattern="A"> <map:redirect-to uri="B" /> </map:match> <map:match pattern="B"> // does real stuff here </map:match> Now, if I call directly http://server/test/A, it correctly redirects me to http://server/test/B (the redirect is relative to the request URI and thus to the mounted sitemap), but if I call http://server/test2/A, it redirects internally to cocoon:/B (ignoring the mount), thus leading to a 404 Not Found. Note that if I rewrite the pipeline A to redirect to cocoon:/B instead of B, it works as expected. Technically speaking, in the first case, the redirection is made by the HttpEnvironment which rely directly on Response.sendRedirect() which, according to the servlet spec, interprets URI relative to the current requestURI if it does not begin with a '/'. In the second case, the redirection is handled by the EnvironmentWrapper created by the SitemapSource, which does not know anything about an eventual mount point when actually processing the redirection. Looking at the code, a relative redirect within a cocoon:// pipeline can only work in the same sitemap then the calling pipeline, as the redirectURL is prefixed with "cocoon:/" before processing (SitemapSource.java, revision 540711, line 366). So my question is: is it a bug ? Or do I have to consider that this is the correct behaviour of the redirector ? If this is considered as a bug, we could simply change the SitemapSource so that when getting a relative redirect, the URL is rewritten and the whole process is run again. What do others think ? Regards, -- www.anyware-services.com Cédric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Innopole 13 - L'Occitane - B.P 97672 - 31676 LABEGE CEDEX - France Ametys: le CMS Web Java Open Source www.ametys.org Ce message et toutes les pièces jointes (le "Message") sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Anyware Services décline toute responsabilité au titre de ce Message s'il a été altéré, déformé, falsifié ou édité, diffusé sans autorisation. ____________________________________________________________ • This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. • Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. • Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Financial Technologies SA unless otherwise specifically stated. • An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. • If you have received this email in error, please notify the sender immediately and delete the original.