On 03.11.2014 12:12, Philip Martin wrote:
> James McCoy <jamessan_at_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
Received on 2014-11-03 12:31:24 CET