Bug 61229 - WebDAV listings fails when a file contains ampersand &
Summary: WebDAV listings fails when a file contains ampersand &
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 8.5.15
Hardware: PC Windows NT
: P2 blocker (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-27 12:20 UTC by Sander Hartogensis
Modified: 2017-06-30 20:58 UTC (History)
3 users (show)



Attachments
webapps webdav folder (13.60 KB, application/x-zip-compressed)
2017-06-27 12:20 UTC, Sander Hartogensis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sander Hartogensis 2017-06-27 12:20:54 UTC
Created attachment 35080 [details]
webapps webdav folder

See the attached test WebDAV folder (webdav.zip). If the WebDAV folder contains a file with an ampersand in the filename, you cannot access the folder at all with WebDAV. I can reproduce it with AnyClient from JSCAPE (in our own product we use jackrabbit for WebDAV access).

Full repro steps:
- JAVA_HOME is 1.8.0_121
- Extract apache-tomcat-8.5.15.zip to a working folder.
- In the webapps directory extract contents of webapps.zip (see attachment)
- In apache-tomcat-8.5.15\bin run: catalina.bat start
- In AnyClient configure a new connection in Site Manager:
-- Host: http://localhost:8080/webdav
-- Protocol: WebDAV
- Connect, click the refresh button, and notice the listing remains empty.
- In a file manager go to webapps\webdav and rename test&.txt to test.txt.
- Get the directory listing again, and notice that it works now.

I tried three Tomcat versions:
8.5.15: has this bug
8.5.14: works fine
7.0.78: works fine

Note that you see the problem only if you access the directory with a WebDAV client, getting the directory listing in a browser works fine.
Comment 1 Mark Thomas 2017-06-29 19:02:46 UTC
Thanks for the test case. I can repeat this locally.

The problem was triggered by r1792460. Since '&' is a legal character in a URI, it is no longer encoded. However, '&' is not  a legal character in XML so not encoding it triggers this issue.

Working on a patch now.
Comment 2 Mark Thomas 2017-06-29 20:22:57 UTC
Fixed in:
- trunk for 9.0.0.M23 onwards
- 8.5.x for 8.5.17 onwards
- 8.0.x for 8.0.46 onwards
- 7.0.x for 7.0.80 onwards