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
Received on 2018-11-04 17:51:37 CET