cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laurent Medioni" <>
Subject RE: [2.1.11] Strange behaviour with a cocoon://, mount and redirect combination
Date Tue, 05 Oct 2010 17:22:47 GMT
I would blame the EnvironmentWrapper for ignoring its prefix property ("test/") when its redirectURL
property is set to "B"...


From: Cédric Damioli [] 
Sent: lundi, 4. octobre 2010 19:49
Subject: Re: [2.1.11] Strange behaviour with a cocoon://, mount and redirect combination

The SitemapSource is executed within the root sitemap, so the redirection leads to an error.


Le 04/10/2010 18:58, Laurent Medioni a écrit : 
" 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 ?


-----Original Message-----
From: Cédric Damioli [] 
Sent: samedi, 2. octobre 2010 17:04
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 pattern="test2/**">
<map:generate src="cocoon://test/{1}" />

In the sub sitemap, I have:

<map:match pattern="A">
<map:redirect-to uri="B" />

<map:match pattern="B">
     // does real stuff here

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 
(, 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 ?


Cédric Damioli
Directeur technique
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 

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.
View raw message