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:[email protected]]
Sent: lundi, 4. octobre 2010 19:49
To: [email protected]
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:[email protected]]
Sent: samedi, 2. octobre 2010 17:04
To: [email protected]
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
[email protected]
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.
