On 03.11.2014 12:12, Philip Martin wrote: > James McCoy <james...@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
