Re: Incomplete xml output when using --xml to non-existent server

On Wed, Mar 2, 2016 at 8:14 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Branko Čibej [mailto:brane_at_apache.org]
>> Sent: woensdag 2 maart 2016 19:08
>> To: dev_at_subversion.apache.org
>> Subject: Re: Incomplete xml output when using --xml to non-existent server
>>
>> On 02.03.2016 15:05, Johan Corveleyn wrote:
>> > Hi all,
>> >
>> > A colleague of mine ran into this, and I'm wondering if it's expected
>> > behavior or a bug:
>> >
>> > For certain commands with the --xml option, the xml output is
>> > incomplete when sending the request to a non-existent server. This can
>> > cause an issue for tools that try to parse the output into some data
>> > structure, and expect correct XML (even though the command has exited
>> > with an error).
>> >
>> > For instance, 'svn info' and 'svn ls' behave thusly (maybe other
>> > commands as well):
>> >
>> > [[[
>> > C:\>svn info --xml https://nonexistent/svn
>> > <?xml version="1.0" encoding="UTF-8"?>
>> > <info>
>> > svn: E170013: Unable to connect to a repository at URL
>> 'https://nonexistent/svn'
>> > svn: E731001: No such host is known.
>> >
>> > C:\>svn ls --xml https://nonexistent/svn
>> > <?xml version="1.0" encoding="UTF-8"?>
>> > <lists>
>> > <list
>> > path="https://nonexistent/svn">
>> > svn: E170013: Unable to connect to a repository at URL
>> 'https://nonexistent/svn'
>> > svn: E731001: No such host is known.
>> > ]]]
>> >
>> > (The 'svn: Exxx' warnings are printed to stderr, while the incomplete
>> > xml output is printed to stdout)
>>
>> This is clearly a bug; stdout should be either empty, or valid XML.
>>
>> In this case I suspect that we're printing the generic XML header too soon.
>
> We produce the output streamingly... would you suggest that we now buffer all output before producing the first result? (Potentially many hundreds of MB on recursive operations, so that would have to be a disk backed buffer when the amount of data gets huge)
>
> I think I asked the same question somewhere before 1.5, and the answer then was +- as I answered now... This is not really fixable in a backwards compatible way as there is no way to express errors in the schema. (How do we express an error to access a file somewhere deep inside a tree? That would make the entire tree invalid as expressed in todays schema)
>

Bert,

Note that a failure to access a file / directory does *not* give this
problem. This incomplete xml only happens when there is a problem
accessing the *server* ("nonexistent" in my example).

As I said in the second part of my mail:

> Contrast this with another failing request, when accessing a
> *non-existent directory* on an existing server:
>
> [[[
> C:\>svn info --xml https://realserver/svn/asdf
> <?xml version="1.0" encoding="UTF-8"?>
> <info>
> svn: warning: W170000: URL 'https://realserver/svn/asdf' non-existent
> in revision 316895
>
> </info>
> svn: E200009: Could not display info for all targets because some
> targets don't exist
>
> C:\>svn ls --xml https://realserver/svn/asdf
> <?xml version="1.0" encoding="UTF-8"?>
> <lists>
> <list
> path="https://realserver/svn/asdf">
> svn: warning: W160013: URL 'https://realserver/svn/asdf' non-existent
> in revision 316895
> </list>
> </lists>
> svn: E200009: Could not list all targets because some targets don't exist
> ]]]

Accessing a non-existent directory on an existing server does yield correct xml.

-- 
Johan