You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by bu...@apache.org on 2004/09/16 18:09:37 UTC

DO NOT REPLY [Bug 31265] New: - filename encoding patch

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=31265>.
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=31265

filename encoding patch

           Summary: filename encoding patch
           Product: Slide
           Version: Nightly
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: WebDAV Server
        AssignedTo: slide-dev@jakarta.apache.org
        ReportedBy: thomas.draier@codeva.net


the getPathInfo() method is supposed to return a decoded path - but the
behaviour is different between different containers when strange characters are
sent. tomcat 4 and 5 do no return the same value. i replaced it with a parsing
of getRequestURI(), which returns what the client has sent without decoding -
and do the same with either tomcat 4 or 5, hopefully also for other servers.
i've also found some problems with the urlEncoding configuration parameter. even
if the system is configured as utf-8, some clients can still send a mix of utf-8
and another encoding - so i added another parameter in Configuration to define
if utf8 should be used or not, and kept the other as a "secondary" encoding. i
changed the decodeString method (the method i previously added), which decodes
either utf-8 or encoding specified in the configuration. and i updated the
fixTomcatURL() method in order to work with these changes.
i changed the propfind method so that the encoding declared in the xml response
match the encoding being used (it was always returning "utf-8")
the "Destination" header should be decoded as the url - for all the clients i've
tested, the same form is used - getHeader() works as getRequestURI(), and does
not decode anything. i do not know about the "Label" header - the clients i
have, except slide client, do not support it now.
finally, i added a transformation for the ? character. that character does not
work with most of the client i've used, but it appears if a character not
supported by the encoding specified in confguration is sent. and then make the
file unusable.

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