You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Michael Sinz <Mi...@sinz.org> on 2005/10/21 21:18:04 UTC

Interesting problem with ":" in mod_dav_svn XML output

Something just "bit me" with XSLT displayed pages from mod_dav_svn.
I say that in quotes as I had already had worked around the problem,
before I even knew about it, for other reasons.

Anyway, the problem is that the ":" character is not escaped in the
"href" attribute of the file and directory elements.

This is a problem as the ":" character is a special character that
separates protocol from port within a URL and thus must be escaped
if it is not serving in that manner.

Thus, the mod_dav_svn XML output below would fail to correctly
link to the file "TestCase-:-.txt" as the browser would complain
about the protocol.

Other special characters are correctly escaped as far as I can see.

When looking at the code, it seems that this is a non-trivial change
since the escaping happens within Apache and that it is a general URI
escaper.  Thus, the net result is that it does not know if the ":" should
be escaped or not (given that it could be part of the "http://" or part
of the "host:port" string)

The code that does this is generated by the server/gen_test_char.c within
Apache.  Since mod_dav_svn uses ap_escape_uri() which is actually a
define to ap_os_escape_path() which looks at the T_OS_ESCAPE_PATH flag
in the table.

The file server/gen_test_char.c generates the table.

Maybe this is one case where some other method would need to be used
since the href field is always just a relative path?

So, I did not make a patch for this (yet) as I would like to get some
input as to the best way to go.  I think this could be handled via a
special case on top of the Apache escaping - since I don't know if there
would be a reasonable way to change Apache on this issue.

-----------------------------output from mod_dav_svn---------------------------

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/insurrection.xsl"?>
<!DOCTYPE svn [
   <!ELEMENT svn   (index)>
   <!ATTLIST svn   version CDATA #REQUIRED
                   href    CDATA #REQUIRED>
   <!ELEMENT index (updir?, (file | dir)*)>
   <!ATTLIST index name    CDATA #IMPLIED
                   path    CDATA #IMPLIED
                   rev     CDATA #IMPLIED>
   <!ELEMENT updir EMPTY>
   <!ELEMENT file  (prop)*>
   <!ATTLIST file  name    CDATA #REQUIRED
                   href    CDATA #REQUIRED>
   <!ELEMENT dir   (prop)*>

   <!ATTLIST dir   name    CDATA #REQUIRED
                   href    CDATA #REQUIRED>
   <!ELEMENT prop  (#PCDATA)>
   <!ATTLIST prop  name    CDATA #REQUIRED>
]>
<svn version="1.2.3 (r15833)"
      href="http://subversion.tigris.org/">
   <index rev="31" path="/trunk/tests/TestCase-:-">
     <updir />
     <file name="TestCase-:-.txt" href="TestCase-:-.txt"></file>
     <file name="test.txt" href="test.txt"></file>
   </index>

</svn>

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Michael Sinz <Mi...@sinz.org>.
Michael Sinz wrote:
> Something just "bit me" with XSLT displayed pages from mod_dav_svn.
> I say that in quotes as I had already had worked around the problem,
> before I even knew about it, for other reasons.

Note that this is not just in XML output but also a problem in the
HTML output from mod_dav_svn

> Anyway, the problem is that the ":" character is not escaped in the
> "href" attribute of the file and directory elements.
> 
> This is a problem as the ":" character is a special character that
> separates protocol from port within a URL and thus must be escaped
> if it is not serving in that manner.

[...]

Note that this may be a security risk.  Since the ":" is not escaped,
a file or directory that has a correctly formatted name could now
cause the browser to do something unwanted on the client's machine and/or
redirect to some remote server.  This is possible due to the fact that
the URL "scheme" is what is parsed before the ":" as long as no "/" exists
before the ":".  Some browsers have special features and capabilities with
certain schemes other than http: and one could even have http: help provide
other data to external servers.

For example (non-dangerous) if a file of the name "http:sinz.com" were to
be in the repository, Subversion/mod_dav_svn would currently make a link that
while looking to go to that file (or directory) would actually go to the
sinz.com site and provide it with referer information.  More complex constructs
are left as a excersice for the reader...

I have just posted a (trivial) patch that fixes the ":" problem and thus
would close whatever potential security issue this may have presented.

	http://svn.haxx.se/dev/archive-2005-10/1105.shtml

The patch is valid in the 1.1.x, 1.2.x, and 1.3.x code base (albeit the
line numbers are slightly different)

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Julian Reschke <ju...@gmx.de>.
Kalle Olavi Niemitalo wrote:
> Julian Reschke <ju...@gmx.de> writes:
> 
> 
>>Kalle Olavi Niemitalo wrote:
>>
>>>Are the "href" attributes in the XML output even documented to be
>>>URLs? 
>>
>>Of course they are.
>>
>><http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.12.3>
> 
> 
> That describes the "href" element in WebDAV, rather than the
> "href" attributes of the "file" and "dir" elements in the
> Subversion-specific directory index schema.

Oh. Sorry.

Best regarsds, Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
Julian Reschke <ju...@gmx.de> writes:

> Kalle Olavi Niemitalo wrote:
>> Are the "href" attributes in the XML output even documented to be
>> URLs? 
>
> Of course they are.
>
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.12.3>

That describes the "href" element in WebDAV, rather than the
"href" attributes of the "file" and "dir" elements in the
Subversion-specific directory index schema.

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Julian Reschke <ju...@gmx.de>.
Kalle Olavi Niemitalo wrote:
> Michael Sinz <Mi...@sinz.org> writes:
> 
> 
>>Anyway, the problem is that the ":" character is not escaped in the
>>"href" attribute of the file and directory elements.
>>
>>This is a problem as the ":" character is a special character that
>>separates protocol from port within a URL and thus must be escaped
>>if it is not serving in that manner.
> 
> 
> Are the "href" attributes in the XML output even documented to be URLs? 

Of course they are.

<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.12.3>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Michael Sinz <Mi...@sinz.org>.
Michael Sinz wrote:
> Kalle Olavi Niemitalo wrote:
> 
>> Michael Sinz <Mi...@sinz.org> writes:
>>
>>> Anyway, the problem is that the ":" character is not escaped in the
>>> "href" attribute of the file and directory elements.
>>>
>>> This is a problem as the ":" character is a special character that
>>> separates protocol from port within a URL and thus must be escaped
>>> if it is not serving in that manner.
>>
>> Are the "href" attributes in the XML output even documented to be URLs? 
> 
> BTW - It is not just in the XML output that this is a problem.  The same
> problem exists in the HTML output.  The following (see below) HTML was
> generated by mod_dav_svn when no XSLT is defined and clicking on the link
> for the "TestCase-:-/" link - since it now looks like a "TestCase-" 
> protocol (vs http) and a path of "-/"
> 
> So, the problem is real and exists even in the basic mod_dav_svn HTML 
> output in addition to the XML output.

[...]

This change was just a test to verify a possible solution to make this
all work correctly.  By pre-pending "./" to each relative URI, the parsing
done by the browser would no longer be within the protocol prefix.  That is,
once it hits a (any) path separator there is no more protocol prefix possible.
(Is this by spec?  The RFC seems to indirectly call for that due to the list
of valid characters in a protocol prefix.)

Anyway, I don't like this patch since it adds "2 bytes" to every entry
just to not have to deal with the ":" character.  It also broke one of my
"hacks" as it assumed the file name only in the href and no path elements
(even if the "./" path element is basically a no-op)  I don't know if there
are others that could be bitten by this issue.

A more correct patch would just deal with the ":" correctly.  So, I guess I
am not submitting this patch for inclusion but rather as a backstop for
someone that may be running into a problem without it.

Index: repos.c
===================================================================
--- repos.c     (revision 16897)
+++ repos.c     (working copy)
@@ -2452,6 +2452,10 @@
          if (is_dir)
            href = apr_pstrcat(entry_pool, href, "/", NULL);

+       /* ### To help solve a problem with the ":" character, make the
+          ### paths actually be "./" relative */
+       href = apr_pstrcat(entry_pool, "./" , href, NULL);
+
          if (gen_html)
            name = href;

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Michael Sinz <Mi...@sinz.org>.
Kalle Olavi Niemitalo wrote:
> Michael Sinz <Mi...@sinz.org> writes:
> 
> 
>>Anyway, the problem is that the ":" character is not escaped in the
>>"href" attribute of the file and directory elements.
>>
>>This is a problem as the ":" character is a special character that
>>separates protocol from port within a URL and thus must be escaped
>>if it is not serving in that manner.
> 
> 
> Are the "href" attributes in the XML output even documented to be URLs? 

BTW - It is not just in the XML output that this is a problem.  The same
problem exists in the HTML output.  The following (see below) HTML was
generated by mod_dav_svn when no XSLT is defined and clicking on the link
for the "TestCase-:-/" link - since it now looks like a "TestCase-" protocol
(vs http:) and a path of "-/"

So, the problem is real and exists even in the basic mod_dav_svn HTML output
in addition to the XML output.

PS - Note that the XML href is escaped specifically for URL/URI use vs the
name is escaped for XML/HTML use.  The same is true in the HTML output as
can be seen below.

-----------------------------------------------------------------------------------
<html><head><title>Revision 31: /trunk/tests</title></head>
<body>
  <h2>Revision 31: /trunk/tests</h2>
  <ul>
   <li><a href="../">..</a></li>
   <li><a href=".svn_index">.svn_index</a></li>
   <li><a href="TestCase-%20-/">TestCase- -/</a></li>

   <li><a href="TestCase-!-/">TestCase-!-/</a></li>
   <li><a href="TestCase-%22-/">TestCase-"-/</a></li>
   <li><a href="TestCase-%23-/">TestCase-#-/</a></li>
   <li><a href="TestCase-$-/">TestCase-$-/</a></li>
   <li><a href="TestCase-%25-/">TestCase-%-/</a></li>
   <li><a href="TestCase-&amp;-/">TestCase-&amp;-/</a></li>

   <li><a href="TestCase-'-/">TestCase-'-/</a></li>
   <li><a href="TestCase-(-/">TestCase-(-/</a></li>
   <li><a href="TestCase-)-/">TestCase-)-/</a></li>
   <li><a href="TestCase-*-/">TestCase-*-/</a></li>
   <li><a href="TestCase-+-/">TestCase-+-/</a></li>
   <li><a href="TestCase-,-/">TestCase-,-/</a></li>

   <li><a href="TestCase---/">TestCase---/</a></li>
   <li><a href="TestCase-.-/">TestCase-.-/</a></li>
   <li><a href="TestCase-:-/">TestCase-:-/</a></li>
   <li><a href="TestCase-%3b-/">TestCase-;-/</a></li>
   <li><a href="TestCase-%3c-/">TestCase-&lt;-/</a></li>
   <li><a href="TestCase-=-/">TestCase-=-/</a></li>

   <li><a href="TestCase-%3e-/">TestCase-&gt;-/</a></li>
   <li><a href="TestCase-%3f-/">TestCase-?-/</a></li>
   <li><a href="TestCase-@-/">TestCase-@-/</a></li>
   <li><a href="TestCase-%5b-/">TestCase-[-/</a></li>
   <li><a href="TestCase-%5c-/">TestCase-\-/</a></li>
   <li><a href="TestCase-%5d-/">TestCase-]-/</a></li>

   <li><a href="TestCase-%5e-/">TestCase-^-/</a></li>
   <li><a href="TestCase-_-/">TestCase-_-/</a></li>
   <li><a href="TestCase-%60-/">TestCase-`-/</a></li>
   <li><a href="TestCase-mv/">TestCase-mv/</a></li>
   <li><a href="TestCase-%7b-/">TestCase-{-/</a></li>
   <li><a href="TestCase-%7c-/">TestCase-|-/</a></li>

   <li><a href="TestCase-%7d-/">TestCase-}-/</a></li>
   <li><a href="TestCase-~-/">TestCase-~-/</a></li>
   <li><a href="TestCase-%7f-/">TestCase--/</a></li>
   <li><a href="mkdirs.pl">mkdirs.pl</a></li>
  </ul>
  <hr noshade><em>Powered by <a href="http://subversion.tigris.org/">Subversion</a> version 1.2.3 (r15833).</em>
</body></html>

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Michael Sinz <Mi...@sinz.org>.
Kalle Olavi Niemitalo wrote:
> Michael Sinz <Mi...@sinz.org> writes:
> 
> 
>>Kalle Olavi Niemitalo wrote:
>>
>>>I think this is a bug.  If Subversion does not allow slashes in
>>>file names, it should say so in the error message, rather than
>>>treat %2F as a directory separator.
>>
>>That is the problem - how would such a file ever be handled at the FS layer or
>>the URI layer - the escaping/unescaping happens before the path is taken apart.
> 
> 
> Well, if the interface of the URI unescaping code makes it
> impossible to preserve the distinction between "%2F" and "/",
> then I think the unescaper should allow just one of them,
> presumably "/", and return an error if it sees the other.

First, who should return the error?  Who should parse the URL/URI and
pick/choose as to what is an error and what is not?  The client side
really should not as it is perfectly legal to "escape" any character
that the client may have problems with.

The good thing is that very few filesystem implementations support the "/"
within a filename/dirname (at least at the interface layer)

> The same applies to "%00" versus end of string

Ahh, the horrible (but easy to use) C-string bites again :-)  Really,
that is a language implementation detail which also exists in many APIs
to filesystems.  Who should error that?  And in what way?

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
Michael Sinz <Mi...@sinz.org> writes:

> Kalle Olavi Niemitalo wrote:
>> I think this is a bug.  If Subversion does not allow slashes in
>> file names, it should say so in the error message, rather than
>> treat %2F as a directory separator.
>
> That is the problem - how would such a file ever be handled at the FS layer or
> the URI layer - the escaping/unescaping happens before the path is taken apart.

Well, if the interface of the URI unescaping code makes it
impossible to preserve the distinction between "%2F" and "/",
then I think the unescaper should allow just one of them,
presumably "/", and return an error if it sees the other.

The same applies to "%00" versus end of string.

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Michael Sinz <Mi...@sinz.org>.
Kalle Olavi Niemitalo wrote:
> Michael Sinz <Mi...@sinz.org> writes:
> 
> 
>>There is a very unlikely (not supported in any reasonable way) case
>>of a repository file/directory having a "/" in it that would be more correctly
>>addressed by using the ap_escape_path_segment form but there is no real benefit
>>to even thinking about that since I have no idea how that would be supported
>>elsewhere within the system and on the physical platforms.  (How would one make
>>such a file?)
> 
> kalle@Astalo:~$ svn info file://localhost/home/kalle/com/subversion/sandbox/trunk/koe
> Path: koe
> Name: koe
> URL: file://localhost/home/kalle/com/subversion/sandbox/trunk/koe
> Repository Root: file://localhost/home/kalle/com/subversion/sandbox
> Repository UUID: 3cd98347-c503-0410-9c4e-e0ef48c90a53
> Revision: 2
> Node Kind: file
> Last Changed Author: kalle
> Last Changed Rev: 2
> Last Changed Date: 2005-10-23 08:38:51 +0300 (Sun, 23 Oct 2005)
> 
> kalle@Astalo:~$ svn cp -m "Test a slash in the file name." file://localhost/home/kalle/com/subversion/sandbox/trunk/koe file://localhost/home/kalle/com/subversion/sandbox/trunk/slashed%2Fname
> /home/kalle/src/FOREIGN-SVK/svn/subversion/libsvn_repos/commit.c:399: (apr_err=160016)
> svn: Path 'slashed' not present
> kalle@Astalo:~$
> 
> I think this is a bug.  If Subversion does not allow slashes in
> file names, it should say so in the error message, rather than
> treat %2F as a directory separator.

That is the problem - how would such a file ever be handled at the FS layer or
the URI layer - the escaping/unescaping happens before the path is taken apart.
So, I don't think there is a good way to handle this or to notice the problem
as its own unique case rather than a missing directory case.

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
Michael Sinz <Mi...@sinz.org> writes:

> There is a very unlikely (not supported in any reasonable way) case
> of a repository file/directory having a "/" in it that would be more correctly
> addressed by using the ap_escape_path_segment form but there is no real benefit
> to even thinking about that since I have no idea how that would be supported
> elsewhere within the system and on the physical platforms.  (How would one make
> such a file?)

kalle@Astalo:~$ svn info file://localhost/home/kalle/com/subversion/sandbox/trunk/koe
Path: koe
Name: koe
URL: file://localhost/home/kalle/com/subversion/sandbox/trunk/koe
Repository Root: file://localhost/home/kalle/com/subversion/sandbox
Repository UUID: 3cd98347-c503-0410-9c4e-e0ef48c90a53
Revision: 2
Node Kind: file
Last Changed Author: kalle
Last Changed Rev: 2
Last Changed Date: 2005-10-23 08:38:51 +0300 (Sun, 23 Oct 2005)

kalle@Astalo:~$ svn cp -m "Test a slash in the file name." file://localhost/home/kalle/com/subversion/sandbox/trunk/koe file://localhost/home/kalle/com/subversion/sandbox/trunk/slashed%2Fname
/home/kalle/src/FOREIGN-SVK/svn/subversion/libsvn_repos/commit.c:399: (apr_err=160016)
svn: Path 'slashed' not present
kalle@Astalo:~$

I think this is a bug.  If Subversion does not allow slashes in
file names, it should say so in the error message, rather than
treat %2F as a directory separator.

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Michael Sinz <Mi...@sinz.org>.
Kalle Olavi Niemitalo wrote:
> Michael Sinz <Mi...@sinz.org> writes:
> 
> 
>>Well, it fixes it by prepending the "./" to the element, much like
>>my kludge patch, only with less overhead (same new allocation) and with
>>the "./" prepended only if there is a ":" before any "/"
>>
>>So, yes, this looks like a good way to fix this.  (My other way was to
>>%3A the ":" but that is not needed by using the ap_os_escape_path() function.
> 
> I think this was a good decision by the Apache team.  There
> typically will be a slash before the colon, so escaping won't be
> necessary.  If there isn't, "./::" is shorter than "%3A%3A" and
> has no semantic difference.

It is an interesting choice since it makes an escaped path dependant on
prior parts of it.  While this is strictly correct, it also makes for bugs
like this one since the ap_escape_uri() did not look if there was a way
to deal with the ":" before a "/" case.  They could have just as easily
done the escaping of ":" until they passed the first "/" in the path.

The real problem is that there is no good way to retrofit this into the
current Apache API since sometimes a complete URI is passed in, not just
the path part, and the ":" characters there need to remain in place.

(No one ever said the URI escaping/encoding is easy if you
only get all or part of a URI and are not told which it is :-)

>>  <li><a href="TestCase-%5c-/">TestCase-\-/</a></li>
> 
> Did you run this test on Windows?  As ap_os_escape_path is
> documented to take "an OS path", I worry that a Windows version
> of Apache might treat the backslash as an OS-specific directory
> separator and helpfully map it to the forward slash used in
> hierarchic URIs.  I did not find such code in server/util.c nor
> in os/win32/util_win32.c, but who knows whether it will be added
> later?

I have not run it on Windows but, if you look at the source to Apache,
the ap_escape_uri(a,b) is just a #define for ap_os_escape_path(a,b,1)
(see include/httpd.h)

I am rather sure that this filename would cause problems on a Windows
client but would not/should not be a problem for a Subversion server
running on Windows (mod_dav_svn or svnserver)

 From what I can see, the path escaping is for RFC 1808 paths and not
local OS paths other than a minor need for some extra work in the
client.  It would be very broken to have Apache running on Windows
handle URLs differently than Apache running on "everything else"

(That is, externally - internally Apache needs to talk to the local OS
file system APIs and thus may need to different work but that is not
what this API is for)

The only difference I see for the escaping rules for different OS versions
is with respect to the T_ESCAPE_SHELL_CMD and it only adds two characters
for that case in WIN32/OS2 land (the \r and % characters)

The T_ESCAPE_PATH_SEGMENT and T_OS_ESCAPE_PATH are both constants for
all platforms.  (T_ESCAPE_PATH_SEGMENT just adds "/" to the T_OS_ESCAPE_PATH)

This can all be seen in the server/gen_test_char.c code, which generates
the character escaping tables that the various escape functions use.

Also, from reading the code and some notes, it seems that the "ap_os_escape_path"
name is a bit of a mistaken name as it is not really an OS specific
concept but may have been thought to have been at one point.

>>Kalle Olavi Niemitalo wrote:
>>
>>>Another option would be to call ap_escape_path_segment and append
>>>the slash only afterward, but then it would have to be appended
>>>separately to both name and href, leading to more complex code.
>>
>>As I said, I tried that - but ap_escape_path_segment() does not deal with
>>the ":" in any way.
> 
> I'm sorry about the misinformation.

No problem - I thought it should have worked too, and to me it seems that it
would have been right "correct" choice since we know the name is just a single
segment.  There is a very unlikely (not supported in any reasonable way) case
of a repository file/directory having a "/" in it that would be more correctly
addressed by using the ap_escape_path_segment form but there is no real benefit
to even thinking about that since I have no idea how that would be supported
elsewhere within the system and on the physical platforms.  (How would one make
such a file?)

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
Michael Sinz <Mi...@sinz.org> writes:

> Well, it fixes it by prepending the "./" to the element, much like
> my kludge patch, only with less overhead (same new allocation) and with
> the "./" prepended only if there is a ":" before any "/"
>
> So, yes, this looks like a good way to fix this.  (My other way was to
> %3A the ":" but that is not needed by using the ap_os_escape_path() function.

I think this was a good decision by the Apache team.  There
typically will be a slash before the colon, so escaping won't be
necessary.  If there isn't, "./::" is shorter than "%3A%3A" and
has no semantic difference.

>   <li><a href="TestCase-%5c-/">TestCase-\-/</a></li>

Did you run this test on Windows?  As ap_os_escape_path is
documented to take "an OS path", I worry that a Windows version
of Apache might treat the backslash as an OS-specific directory
separator and helpfully map it to the forward slash used in
hierarchic URIs.  I did not find such code in server/util.c nor
in os/win32/util_win32.c, but who knows whether it will be added
later?

> Kalle Olavi Niemitalo wrote:
>> Another option would be to call ap_escape_path_segment and append
>> the slash only afterward, but then it would have to be appended
>> separately to both name and href, leading to more complex code.
>
> As I said, I tried that - but ap_escape_path_segment() does not deal with
> the ":" in any way.

I'm sorry about the misinformation.

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Michael Sinz <Mi...@sinz.org>.
Kalle Olavi Niemitalo wrote:
> Michael Sinz <Mi...@sinz.org> writes:
> 
>>Michael Sinz wrote:
>>
>>>Kalle Olavi Niemitalo wrote:
>>>
>>>>Are the "href" attributes in the XML output even documented to be
>>>>URLs? 
>>>
>>> From what I know, they are "relative" URLs, specifically formatted
>>>(and escaped) to be that.  (Check out subversion/mod_dav_svn/repos.c around
>>>line 3331 or so.)
>>
>>       ^^^^ - make that line 2461 in r16897 in /trunk.
> 
> 
> Okay.  This is in subversion/mod_dav_svn/repos.c (dav_svn_deliver):
> 
> | 	/* We quote special characters in both XML and HTML. */
> | 	name = apr_xml_quote_string(entry_pool, name, !gen_html);
> | 
> |         href = ap_escape_uri(entry_pool, href);
> | 	href = apr_xml_quote_string(entry_pool, href, 1);
> 
> httpd-2.0.53/include/httpd.h says:
> 
> | /**
> |  * Escape a path segment, as defined in RFC 1808
> |  * @param p The pool to allocate from
> |  * @param s The path to convert
> |  * @return The converted URL
> |  */
> | AP_DECLARE(char *) ap_escape_path_segment(apr_pool_t *p, const char *s);
> | /**
> |  * convert an OS path to a URL in an OS dependant way.
> |  * @param p The pool to allocate from
> |  * @param path The path to convert
> |  * @param partial if set, assume that the path will be appended to something
> |  *        with a '/' in it (and thus does not prefix "./")
> |  * @return The converted URL
> |  */
> | AP_DECLARE(char *) ap_os_escape_path(apr_pool_t *p, const char *path, int partial);
> | /** @see ap_os_escape_path */
> | #define ap_escape_uri(ppool,path) ap_os_escape_path(ppool,path,1)
> 
> httpd-2.0.53/server/util.c (ap_os_escape_path) checks for colons
> if partial==0.  So the following patch (which I cannot test now)
> should fix this.

Well, it fixes it by prepending the "./" to the element, much like
my kludge patch, only with less overhead (same new allocation) and with
the "./" prepended only if there is a ":" before any "/"

So, yes, this looks like a good way to fix this.  (My other way was to
%3A the ":" but that is not needed by using the ap_os_escape_path() function.

(I should have seen that - I was looking at using ap_escape_path_segment()
before appending the "/" since we know the path segment is just that but
it still does not escape the ":" since it seems Apache does not escape ":"
but depends on the fact that there will be a "/" before any ":" in the path.)

---- Output from mod_dav_svn in HTML mode - XML is equally fixed. ----
<html><head><title>Revision 31: /trunk/tests</title></head>
<body>
  <h2>Revision 31: /trunk/tests</h2>
  <ul>
   <li><a href="../">..</a></li>
   <li><a href=".svn_index">.svn_index</a></li>
   <li><a href="TestCase-%20-/">TestCase- -/</a></li>

   <li><a href="TestCase-!-/">TestCase-!-/</a></li>
   <li><a href="TestCase-%22-/">TestCase-"-/</a></li>
   <li><a href="TestCase-%23-/">TestCase-#-/</a></li>
   <li><a href="TestCase-$-/">TestCase-$-/</a></li>
   <li><a href="TestCase-%25-/">TestCase-%-/</a></li>
   <li><a href="TestCase-&amp;-/">TestCase-&amp;-/</a></li>

   <li><a href="TestCase-'-/">TestCase-'-/</a></li>
   <li><a href="TestCase-(-/">TestCase-(-/</a></li>
   <li><a href="TestCase-)-/">TestCase-)-/</a></li>
   <li><a href="TestCase-*-/">TestCase-*-/</a></li>
   <li><a href="TestCase-+-/">TestCase-+-/</a></li>
   <li><a href="TestCase-,-/">TestCase-,-/</a></li>

   <li><a href="TestCase---/">TestCase---/</a></li>
   <li><a href="TestCase-.-/">TestCase-.-/</a></li>
   <li><a href="./TestCase-:-/">TestCase-:-/</a></li>
   <li><a href="TestCase-%3b-/">TestCase-;-/</a></li>
   <li><a href="TestCase-%3c-/">TestCase-&lt;-/</a></li>
   <li><a href="TestCase-=-/">TestCase-=-/</a></li>

   <li><a href="TestCase-%3e-/">TestCase-&gt;-/</a></li>
   <li><a href="TestCase-%3f-/">TestCase-?-/</a></li>
   <li><a href="TestCase-@-/">TestCase-@-/</a></li>
   <li><a href="TestCase-%5b-/">TestCase-[-/</a></li>
   <li><a href="TestCase-%5c-/">TestCase-\-/</a></li>
   <li><a href="TestCase-%5d-/">TestCase-]-/</a></li>

   <li><a href="TestCase-%5e-/">TestCase-^-/</a></li>
   <li><a href="TestCase-_-/">TestCase-_-/</a></li>
   <li><a href="TestCase-%60-/">TestCase-`-/</a></li>
   <li><a href="TestCase-mv/">TestCase-mv/</a></li>
   <li><a href="TestCase-%7b-/">TestCase-{-/</a></li>
   <li><a href="TestCase-%7c-/">TestCase-|-/</a></li>

   <li><a href="TestCase-%7d-/">TestCase-}-/</a></li>
   <li><a href="TestCase-~-/">TestCase-~-/</a></li>
   <li><a href="TestCase-%7f-/">TestCase--/</a></li>
   <li><a href="mkdirs.pl">mkdirs.pl</a></li>
  </ul>
  <hr noshade><em>Powered by <a href="http://subversion.tigris.org/">Subversion</a> version 1.2.3 (r15833).</em>

</body></html>
----------------------------------------------------------------------

I would like to suggest that this be back-ported to 1.2.x and 1.3.x since
it is needed to make files and directories with ":" in them work correctly
in the mod_dav_svn HTML and XML output.  I guess I should write up a formal
patch...

Index: subversion/mod_dav_svn/repos.c
===================================================================
--- subversion/mod_dav_svn/repos.c      (revision 16897)
+++ subversion/mod_dav_svn/repos.c      (working copy)
@@ -2458,7 +2458,7 @@
         /* We quote special characters in both XML and HTML. */
         name = apr_xml_quote_string(entry_pool, name, !gen_html);

-        href = ap_escape_uri(entry_pool, href);
+        href = ap_os_escape_path(entry_pool, href, 0);
         href = apr_xml_quote_string(entry_pool, href, 1);

          if (gen_html)
===================================================================

> Another option would be to call ap_escape_path_segment and append
> the slash only afterward, but then it would have to be appended
> separately to both name and href, leading to more complex code.

As I said, I tried that - but ap_escape_path_segment() does not deal with
the ":" in any way.  It assumes that a "/" before it will effectively
make the ":" not a special character as per the URL/URI specification.
Thus, the only real "escaping" of the ":" is using "partial = 0" in the
ap_os_escape_path() function - and it only prepends the "./" to make that
work.

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
Michael Sinz <Mi...@sinz.org> writes:

> Michael Sinz wrote:
>> Kalle Olavi Niemitalo wrote:
>>> Are the "href" attributes in the XML output even documented to be
>>> URLs? 
>>  From what I know, they are "relative" URLs, specifically formatted
>> (and escaped) to be that.  (Check out subversion/mod_dav_svn/repos.c around
>> line 3331 or so.)
>        ^^^^ - make that line 2461 in r16897 in /trunk.

Okay.  This is in subversion/mod_dav_svn/repos.c (dav_svn_deliver):

| 	/* We quote special characters in both XML and HTML. */
| 	name = apr_xml_quote_string(entry_pool, name, !gen_html);
| 
|         href = ap_escape_uri(entry_pool, href);
| 	href = apr_xml_quote_string(entry_pool, href, 1);

httpd-2.0.53/include/httpd.h says:

| /**
|  * Escape a path segment, as defined in RFC 1808
|  * @param p The pool to allocate from
|  * @param s The path to convert
|  * @return The converted URL
|  */
| AP_DECLARE(char *) ap_escape_path_segment(apr_pool_t *p, const char *s);
| /**
|  * convert an OS path to a URL in an OS dependant way.
|  * @param p The pool to allocate from
|  * @param path The path to convert
|  * @param partial if set, assume that the path will be appended to something
|  *        with a '/' in it (and thus does not prefix "./")
|  * @return The converted URL
|  */
| AP_DECLARE(char *) ap_os_escape_path(apr_pool_t *p, const char *path, int partial);
| /** @see ap_os_escape_path */
| #define ap_escape_uri(ppool,path) ap_os_escape_path(ppool,path,1)

httpd-2.0.53/server/util.c (ap_os_escape_path) checks for colons
if partial==0.  So the following patch (which I cannot test now)
should fix this.


Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Michael Sinz <Mi...@sinz.org>.
Michael Sinz wrote:
> Kalle Olavi Niemitalo wrote:
> 
>> Michael Sinz <Mi...@sinz.org> writes:
>>
>>
>>> Anyway, the problem is that the ":" character is not escaped in the
>>> "href" attribute of the file and directory elements.
>>>
>>> This is a problem as the ":" character is a special character that
>>> separates protocol from port within a URL and thus must be escaped
>>> if it is not serving in that manner.
>>
>>
>>
>> Are the "href" attributes in the XML output even documented to be URLs? 
> 
> 
>  From what I know, they are "relative" URLs, specifically formatted
> (and escaped) to be that.  (Check out subversion/mod_dav_svn/repos.c around
> line 3331 or so.)
        ^^^^ - make that line 2461 in r16897 in /trunk.

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Michael Sinz <Mi...@sinz.org>.
Kalle Olavi Niemitalo wrote:
> Michael Sinz <Mi...@sinz.org> writes:
> 
> 
>>Anyway, the problem is that the ":" character is not escaped in the
>>"href" attribute of the file and directory elements.
>>
>>This is a problem as the ":" character is a special character that
>>separates protocol from port within a URL and thus must be escaped
>>if it is not serving in that manner.
> 
> 
> Are the "href" attributes in the XML output even documented to be URLs? 

 From what I know, they are "relative" URLs, specifically formatted
(and escaped) to be that.  (Check out subversion/mod_dav_svn/repos.c around
line 3331 or so.)

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Interesting problem with ":" in mod_dav_svn XML output

Posted by Kalle Olavi Niemitalo <ko...@iki.fi>.
Michael Sinz <Mi...@sinz.org> writes:

> Anyway, the problem is that the ":" character is not escaped in the
> "href" attribute of the file and directory elements.
>
> This is a problem as the ":" character is a special character that
> separates protocol from port within a URL and thus must be escaped
> if it is not serving in that manner.

Are the "href" attributes in the XML output even documented to be URLs?