https://issues.apache.org/bugzilla/show_bug.cgi?id=56480
Bug ID: 56480
Summary: mod_dav: PROPFIND walker doesn't encode hrefs
properly.
Product: Apache httpd-2
Version: 2.4.9
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: mod_dav
Assignee: [email protected]
Reporter: [email protected]
This is further fall out from the 54611 and the subsequent attempt to fix the
ABI in PR 55397.
An easy way to see this issue is to setup mod_dav/mod_dav_svn like so:
<Location /svn>
DAV svn
SVNPath /path/to/repo
</Location>
And then do the following
svnadmin create /path/to/repo
echo something | svnmucc -m 'add a file' -- put - 'http://127.0.0.1/svn/a<b'
svn ls http://127.0.0.1/svn
Various versions of Subversion will produce different error message. For
example (but by no means likely to be exhaustive):
svn: E130003: Malformed XML: not well-formed (invalid token)
svn: E175002: PROPFIND of '/svn/!svn/rvr/2': 207 Multi-Status
(http://127.0.0.1)
svn: E175009: XML parsing failed: (207 Multi-Status)
dav_xml_escape_uri() assumes that the URI is already encoded and as such
presumes that it only needs to do XML escaping if there is an '&' character in
the URI. Since characters like '<' and '>' would already be encoded by the URI
encoding. Prior to PR 55397 this function also URI encoded, but this was
removed since it resulted in double encoding.
During the work for PR 55397 my attempt to audit for all places Subversion set
resource->uri fields apparently missed the PROPFIND walker case (or I wrongly
presumed that the uri we being set was already encoded). This presents the
problem that now not even Subversion in consistent. Which means we essentially
have some cases where resource->uri must be encoded and some cases where it
does not.
Changing the filename to 'a<&b' will make the symptom disappear for 1.7.x/1.8.x
Subversion clients because that will trigger XML encoding from
dav_xml_escape_uri(). However, 1.6.x clients (and probably older clients) are
not happy the the URI not being URI encoded (even though the XML is valid now)
and produce an error like this:
svn: Unable to parse URL '/svn/!svn/bc/1/a<&b'
A similar behavior was noted by Stephane Chazelas on PR 55397, though he saw
the issue with a filename with a space in it (again valid XML but not valid URI
encoding) and running log on the path. Stephane had also made a bug over at
Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641
So simply fixing to properly emit valid XML is not enough in and of itself. It
will take further thought and investigation as to what the proper fix is here.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
