cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Damioli <cedric.dami...@anyware-services.com>
Subject [2.1.11] Strange behaviour with a cocoon://, mount and redirect combination
Date Sat, 02 Oct 2010 15:03:59 GMT
  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,

-- 
Cédric Damioli
ANYWARE SERVICES
http://www.anyware-services.com
http://www.ametys.org



Mime
View raw message