Bug 31265 - filename encoding patch
Summary: filename encoding patch
Status: NEW
Alias: None
Product: Slide
Classification: Unclassified
Component: WebDAV Server (show other bugs)
Version: Nightly
Hardware: All All
: P3 normal with 2 votes (vote)
Target Milestone: ---
Assignee: Slide Developer List
: 32025 (view as bug list)
Depends on:
Blocks: 31521
  Show dependency tree
Reported: 2004-09-16 16:09 UTC by Thomas Draier
Modified: 2009-06-10 13:25 UTC (History)
1 user (show)

patch to apply (16.85 KB, patch)
2004-09-16 16:12 UTC, Thomas Draier
Details | Diff
there was a few system.out left in previous patch - use this one instead (16.85 KB, patch)
2004-09-17 09:48 UTC, Thomas Draier
Details | Diff
updated patch (16.30 KB, patch)
2004-12-30 12:47 UTC, Thomas Draier
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Draier 2004-09-16 16:09:36 UTC
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.
Comment 1 Thomas Draier 2004-09-16 16:12:16 UTC
Created attachment 12752 [details]
patch to apply
Comment 2 Thomas Draier 2004-09-17 09:48:27 UTC
Created attachment 12758 [details]
there was a few system.out left in previous patch - use this one instead
Comment 3 Thomas Draier 2004-11-02 17:16:03 UTC
*** Bug 32025 has been marked as a duplicate of this bug. ***
Comment 4 Thomas Draier 2004-12-30 12:47:26 UTC
Created attachment 13862 [details]
updated patch
Comment 5 Mark Thomas 2009-06-10 13:25:15 UTC
Reset assignee so mails go to list.