Re: XWiki: au sujet d'un ancien patch i18n...
Hi Gilles, On Apr 27, 2007, at 10:41 AM, Gilles Serasset wrote:
Hi Vincent, Hi all,
mmm, sorry, I just tried to figfure out the problems from the doc. There is a problem already here:
First, the getXXX method do not return the same kind of info:
getServletPath() - decoded getPathInfo() - decoded getRequestURI() - remain encoded getContextPath() - remain encoded getPathTranslated() - remain decoded
You are using getServletPath which returns a decoded string when getRequestURI gives you a encoded string. Hence, if a non ascii char is used in the ServletPath, the length of the servletPath will be shorter than its encoded conterpart.
Yes this is a limitation and I assumed (probably wrongly) that servlet path wouldn't contain non ascii chars. If we have a better solution I'm all for it...
Second, you don't have to fix the encoding anymore as it is not (incorrectly) decoded by the container. However, you have to decode it correctly using the java.net.URLDecoder class (and passing it you wiki encoding).
I don't understand what you're saying here. All I can say is that the existing code wasn't working at all and it now works in all cases I've tried except when the user enters non ascii chars directly in the URL. Creating pages/links using XWiki works fine. We discussed this with Sergiu and we'd like to modify xwiki so that: - we assume that all URLs we get are URL encodings of UTF8 chars always - when we generate URLs we UTF8 encode them (and then URL encode them)
Third, in the case where you call getPathInfo, you should put:
path = fixDecodedURI(request, request.getPathInfo());
This is what you had before but it wasn't working... That's what I fixed :)
Sorry, I'm teaching all day, so can't tell you more now...
Thanks -Vincent
Regards, Gilles, On 25 avr. 07, at 16:01, Vincent Massol wrote:
Hi Gilles (and everyone interested),
I have modified today the XWiki.getDocumentName() method. I've seen that you had modified it in the past to add the call to fixDecodedURI(). I think it's no longer required but I'd like to have your opinion on that.
Here's the modified version:
public String getDocumentName(XWikiRequest request, XWikiContext context) { [...] else { // TODO: Introduce a XWikiURL class in charge of getting the information relevant // to XWiki from a request URL (action, space, document name, file, etc)
// Important: We cannot use getPathInfo() as the container encodes it and different // containers encode it differently, depending on their internal behavior and how // they are configured. Thus to make this container- proof we use the // getRequestURI() which isn't modified by the container and is thus only // URL-encoded.
// Note: Ideally we should modify the getDocumentNameFromPath method but in order // not to introduce any new bug right now we're reconstructing a path info that we // pass to it using the following algorithm: // path info = requestURI - (contextPath + servletPath) String path; if (!request.getRequestURI().startsWith( request.getContextPath() + request.getServletPath())) { log.warn("Request URI [" + request.getRequestURI() + "] should have matched " + "context path [" + request.getContextPath() + "] and servlet path [" + request.getServletPath() + "]"); // Even though this branch shouldn't get executed we never know what containers // will return and thus in order to be safe we fall back to the previous // behavior which was to use getPathInfo() for getting the path (with the // potential issue with i18n encoding as stated above). path = request.getPathInfo(); } else { path = request.getRequestURI().substring( request.getContextPath().length() + request.getServletPath().length()); }
// TODO: I think it's safe to remove the fixDecodedURI now that we're not using // getPathInfo() and thus the container doesn't encode anything but I don't want // to break anything at this late stage (we're releasing 1.0 RC2). Remove it when // we start working on 1.1. docname = getDocumentNameFromPath(fixDecodedURI(request, path), context); } } return docname; }
Thanks a lot -Vincent
-- Gilles Sérasset GETALP-LIG BP 53 - F-38041 Grenoble Cedex 9 Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75
Hi, On 27 avr. 07, at 10:49, Vincent Massol wrote:
Yes this is a limitation and I assumed (probably wrongly) that servlet path wouldn't contain non ascii chars. If we have a better solution I'm all for it...
Sorry, I don't have any other idea...
Second, you don't have to fix the encoding anymore as it is not (incorrectly) decoded by the container. However, you have to decode it correctly using the java.net.URLDecoder class (and passing it you wiki encoding).
I don't understand what you're saying here. All I can say is that the existing code wasn't working at all and it now works in all cases I've tried except when the user enters non ascii chars directly in the URL. Creating pages/links using XWiki works fine.
We discussed this with Sergiu and we'd like to modify xwiki so that: - we assume that all URLs we get are URL encodings of UTF8 chars always - when we generate URLs we UTF8 encode them (and then URL encode them)
Well, you can disregard, my remark, as I did not saw that the URL is decoded correctly afterwards (by getDocumentNameFromPath).
Third, in the case where you call getPathInfo, you should put:
path = fixDecodedURI(request, request.getPathInfo());
This is what you had before but it wasn't working... That's what I fixed :)
Forget it, I only meant that in the "fail safe" case (where getRequestURI does not match context+servlet) you could fix the encoding, but there is no real reason, as this is not something to be expected... Conclusion is: just remove the fix... method which does nothing at all now... Regards, Gilles -- Gilles Sérasset GETALP-LIG 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 -
Vincent Massol