On 04.11.2018 17:47, Branko Čibej wrote: > 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.
FWIW, the fix could be as simple as GitHub's server returning something like DAV: http://github.com/fake-svn-server in their response headers ... -- Brane