[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 20:11:14 +0100

On 04.11.2018 18:57, Thorsten Schöning wrote:
> Guten Tag Branko Čibej,
> am Sonntag, 4. November 2018 um 17:47 schrieben Sie:
>
>> I'm not sure what you mean by "handles more than only DAV successfully"
> I thought it might be possible that GitHub answers differently but
> properly, because the other check mentioned something about HTTP v2.
> Because of TLS, I was unable to look at the requests and responses
> then, but it's like you said, they don't provide DAV-headers in their
> response to OPTION.
>
>> And yes, the HTTP/DAV specification requires that header to be present
>> in the response.
> Which you didn't care about before and things worked for some years
> for some users.

We made this change because users complained about unhelpful error
messages when they tried to connect to a server that did not even
implement HTTP/DAV. The error message was "Malformed XML in response"
which wasn't exactly helpful for diagnosing the problem.

I admit I didn't have GitHub in mind when I added this check. ...

> Now "we" need to get GitHub to change their
> implementation and I didn't even get an automatic bot-reply to my
> question on Friday yet. :-) Lets see how things are going after I send
> them this thread...

I keep wondering why the GitHub staff didn't contact us when they
implemented their SVN-like server. This might all have been avoided if
they had. We already spent time trying to work around GitHub's faulty
implementation (q.v. r1707164), but there's a limit to how much we can
or should do. The protocols in question are quite well documented after
all, both in RFCs and in our own notes.

-- Brane
Received on 2018-11-04 20:11:24 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.