Non ascii characters in doc names, need advices for patch
Hi all, I filed a jira issue concerning the management of doc names that use non ascii char (which poses problems to setup using non iso-latin-1 encoding). The bug is easy to see: setup a utf-8 xwiki and create a page using name "été" for instance. Xwiki redirects you to: http://localhost:8080/xwiki/bin/edit/Main/%C3%A9t%C3%A9? template=&parent=&title=%E9t%E9 As you can see the page name is urlEncoded using UTF-8 but the aram part is encoded using ISO-latin-1 Digging into the code, this redirect is done by create.vm: $response.sendRedirect($newdoc.getURL("edit", "template=${template} &parent=${parent}${auxparams}&title=$title")) the getURL method encodes the page name, but leaves the action string untouched. Somewhere deep in the java standard servlet API, this untouched string has to be encoded and somehow is encoded in iso (I still don't know why nor where... My question is: there are 2 ways to deal with this pb: 1. expect vm macros to explicitely call a urlEncode method when an URL is built. 2. expect the sendRedirect Method to check and encode unproperly encoded URLs. I'd vote for the first solution as the second may lead to nasty results, but I definitelly need your advice for submitting a patch for this. Regards, Gilles, -- Gilles Sérasset GETA-CLIPS-IMAG (UJF, INPG & CNRS) BP 53 - F-38041 Grenoble Cedex 9 Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75
Hi, I know this problem, and it needs to be fixed, indeed. On 2/16/07, Gilles Serasset <Gilles.Serasset@imag.fr> wrote:
Hi all,
[snip] My question is: there are 2 ways to deal with this pb:
1. expect vm macros to explicitely call a urlEncode method when an URL is built. 2. expect the sendRedirect Method to check and encode unproperly encoded URLs.
There is a third option. The code associating URL-s with documents should know what is the encoding setting, meaning that the URL should be properly generated AND recognized, because the problem is not only with the generated URL, but with the accessed document name also. I'd vote for the first solution as the second may lead to nasty
results, but I definitelly need your advice for submitting a patch for this.
It would e great if you could fix this :) Regards, Gilles,
-- Gilles Sérasset GETA-CLIPS-IMAG (UJF, INPG & CNRS) BP 53 - F-38041 Grenoble Cedex 9 Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75
Sergiu Dumitriu -- http://purl.org/net/sergiu
Hi Sergiu, On 17 févr. 07, at 18:34, Sergiu Dumitriu wrote:
Hi,
I know this problem, and it needs to be fixed, indeed.
On 2/16/07, Gilles Serasset <Gilles.Serasset@imag.fr > wrote: Hi all,
[snip]
My question is: there are 2 ways to deal with this pb:
1. expect vm macros to explicitely call a urlEncode method when an URL is built. 2. expect the sendRedirect Method to check and encode unproperly encoded URLs.
There is a third option. The code associating URL-s with documents should know what is the encoding setting, meaning that the URL should be properly generated AND recognized, because the problem is not only with the generated URL, but with the accessed document name also.
Yes this problem appears, but later in the creation cycle. When using the form, the name is correctly retrieved, but a part of the resulting url is not explicitely encoded, leading to a ill-formed URL. This is only this bug that I'm currently dealing with. I'll then try to see why the form fields are correctly retrieved, but not the doc name in the url.
I'd vote for the first solution as the second may lead to nasty results, but I definitelly need your advice for submitting a patch for this.
It would e great if you could fix this :)
The fix will be to add a urlEncode method callable from velocity (in XWiki class I think) and modify the skin so that it corrctly encode parts of the url it builds. Regards, Gilles, -- Gilles Sérasset GETA-CLIPS-IMAG (UJF, INPG & CNRS) BP 53 - F-38041 Grenoble Cedex 9 Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75
participants (2)
-
Gilles Serasset -
Sergiu Dumitriu