[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problems accessing GitHub's SVN-bridge with SVN 1.11

From: Branko Čibej <brane_at_apache.org>
Date: Sun, 4 Nov 2018 17:47:19 +0100

On 04.11.2018 17:06, Thorsten Schöning wrote:
> Guten Tag Thorsten Schöning,
> am Sonntag, 4. November 2018 um 16:42 schrieben Sie:
>
>> Others have the same problem and while it is true that GitHub might
>> have implemented something on their own, it might help to have a look
>> at the changes between 1.10 and 1.11 regarding the protocol.
> Guess I found it:
>
>> * Better error when http:// URL is not a Subversion repository (r1825302)
>> /* Bail out early if we're not talking to a DAV server.
>> Note that this check is only valid if we've received a success
>> response; redirects and errors don't count. */
>> if (opt_ctx->handler->sline.code >= 200
>> && opt_ctx->handler->sline.code < 300
>> && !opt_ctx->received_dav_header)
>> {
>> return svn_error_createf
>> (SVN_ERR_RA_DAV_OPTIONS_REQ_FAILED, NULL,
>> _("The server at '%s' does not support the HTTP/DAV protocol"),
>> session->session_url_str);
>> }
> "received_dav_header" is only set at one place, isn't that check
> wrong? The code handles more than only DAV successfully from my point
> of view:

I'm not sure what you mean by "handles more than only DAV successfully"
... this code only checks if we received any DAV: header in the response
to the OPTIONS request, no more and no less. HTTP/DAV and Subversion's
HTTP protocol use that for capability negotiation at the start of a session.

And yes, the HTTP/DAV specification requires that header to be present
in the response.

-- Brane
Received on 2018-11-04 17:47:27 CET

This is an archived mail posted to the Subversion Users mailing list.