subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@wandisco.com>
Subject Re: Regression in dirent_walker with malformed DAV responses
Date Mon, 03 Nov 2014 11:30:47 GMT
On 03.11.2014 12:12, Philip Martin wrote:
> James McCoy <jamessan@debian.org> writes:
>
>> HTTP/1.1 207 Multi-Status
>> Date: Sat, 01 Nov 2014 03:59:48 GMT
>> Server: Oracle-Application-Server-11g
>> Content-Length: 670
>> Content-Type: text/xml; charset="utf-8"
>> Content-Language: en
>>
>> <?xml version="1.0" encoding="utf-8"?>
>> <D:multistatus xmlns:D="DAV:" xmlns:ns1="http://subversion.tigris.org/xmlns/dav/"
xmlns:ns0="DAV:">
>> <D:response xmlns:lp1="DAV:" xmlns:lp2="http://subversion.tigris.org/xmlns/dav/">
>> <D:href>/svn/vbox/!svn/bc/53112/trunk/COPYING</D:href>
>> <D:propstat>
>> <D:prop>
>> <lp1:resourcetype/>
>> <lp1:getcontentlength>%ld</lp1:getcontentlength>
> I wonder how the server generated that?  In our code it is generated in
> liveprops.c:insert_prop_internal
>
>       value = apr_psprintf(scratch_pool, "%" SVN_FILESIZE_T_FMT, len);
>
> where SVN_FILESIZE_T_FMT is a format specifier such as "ld".  If the
> Solaris port has defined SVN_FILESIZE_T_FMT as "%ld", rather than "ld",
> the resulting format string would be "%%ld" and would lead to the ouput
> shown above.  The difficulty here is that breaking the DAV code like
> that would also break the FSFS backend code and the repositories would
> not work.  Perhaps this server isn't using our code?
>
> The patch below makes the client more lenient.  Do people think the
> client should be working around server bugs like this?

Definitely not. The server is either buggy or patched. Either the bug,
or the patch, could be meant as a vehicle for attacks on the client.
Therefore, the client must only accept completely valid responses from
the server.

-- Brane


Mime
View raw message