On 06.02.2018 18:35, Branko Čibej wrote:
> Earlier today, Julian noted the following on IRC:
>
> $ svn ls http://svn.apache.org/foo
> svn: E170013: Unable to connect to a repository at URL 'http://svn.apache.org/foo'
> svn: E175009: The XML response contains invalid XML
> svn: E130003: Malformed XML: no element found
>
>
> While the first error (Unable to connect ...) makes sense, the errors
> about invalid XML do not. It turns out that these errors are generated
> when ra_serf tries to parse the OPTIONS response during server
> capability negotiation:
>
> $ curl -i -X OPTIONS http://svn.apache.org/foo
> HTTP/1.1 200 OK
> Date: Tue, 06 Feb 2018 16:31:51 GMT
> Server: Apache/2.4.7 (Ubuntu)
> Allow: GET,HEAD,POST,OPTIONS
> Content-Length: 0
>
>
> It turns out that our Expat response handler does not check the response
> Content-Length header nor the Content-Type. I was going to add these
> checks so that we can generate better error messages, but I'm not too
> familiar with ra_serf so I wonder if there's a chance that adding these
> checks would break anything.
>
> As far as I can see, mod_dav_svn will always correctly set at least
> Content-Type (Content-Length is not relevant for chunked responses).
Seeing that the OPTIONS response is expected to be empty, I implemented
a simple check that we received any DAV headers in the response. The
error message now looks like this:
$ svn ls http://svn.apache.org/foo
svn: E170013: Unable to connect to a repository at URL 'http://svn.apache.org/foo'
svn: E175003: The server does not support the HTTP/DAV protocol
Ideas for better wording wold be most welcome.
-- Brane
Received on 2018-02-06 22:10:34 CET