DO NOT REPLY [Bug 34679] New: - URL encoding/decoding or accentuaed ressources broken

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34679>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34679

           Summary: URL encoding/decoding or accentuaed ressources broken
           Product: Slide
           Version: 2.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: critical
          Priority: P1
         Component: WebDAV Server
        AssignedTo: slide-dev@jakarta.apache.org
        ReportedBy: delbd@oma.be


Servlet is unable to interpret href url for ressources with accents or other    
non US-ASCII filename it has send itself.    
    
whole url decoding process is broken under a slide+tomcat (did not check with   
other containers)   
   
However, typing accentuated characters on the url bar directly does allow   
access to the ressource, because client send an uri with a different url   
encoding which does not mess (the same format it uses for a put).   
    
  
Tested with:  
novell webdav client  
windows 2000 web folders  
DAVExplorer  
kio:webdav   
 
Analysis: 
The value received by req.getPathInfo() in WebdavUtils.getRelativePath() is 
already broken as container already intrepreted this as a 'classical' 
urlencode. What i mean is value of req.getPathInfo() has all %hh converted to 
exactly one character while this was encoded supposing it were utf-8 2 byte 
characters. So instead of t��st i get téèst. 
There seems to be a method named fixTomcatURL() but which does exactly the 
opposite of it job. At the output of this 'fix' the uri is converted to 
téèst. As you may guess slide has lost of difficulties to understand 
this :) 
 
This is a big problem as it renders public acces to a slide webdav folder 
useless. If someone puts a ressource with a non us-ascii character, this make 
this ressource unmodifiable! 
 
 
Suggestion: Stick to classical url encoding, let container manage the uri, 
they do that quite well using the HttpServletResponse.encodeURL()  !! 
Trying to by pass container in url encoding/decoding can only lead to such 
problems and weirdness.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org