[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: Wed, 19 Dec 2018 00:53:13 +0100

On 15.11.2018 21:18, Branko Čibej wrote:
> On 15.11.2018 17:27, Branko Čibej wrote:
>> [Moved from users@]
>>
>> On 06.11.2018 19:16, Branko Čibej wrote:
>>> On 04.11.2018 20:11, Branko Čibej wrote:
>>>> 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. ...
>>> I added a test case to our suite that tries the following command:
>>>
>>> svn info https://github.com/apache/subversion/trunk
>>>
>>>
>>> It runs on one of our build slaves, so we'll know fairly soon when (if)
>>> GitHub deploys a fix. And, of course, we'll also know if this feature
>>> breaks again in future.
>>>
>>> http://svn.apache.org/r1845942
>> I created SVN-4789 to track this and added a patch with a possible fix.
>> I did not commit it because it contains what is, in my opinion, a really
>> horrible hack; but it does let our client work against
>> https://github.com again. I would very much prefer that GitHub adds that
>> trivial one-liner fix to their bridge implementation. However, if this
>> issue persists and prevents users from migrating to 1.11.x and later, we
>> may have to use this hack under protest. Note that it is in some ways
>> similar to the now-defunct ASP.NET hack.
>>
>> [[[
>> Hack ra_serf to work with GitHub's bridge again.
>>
>> * subversion/libsvn_ra_serf/options.c
>> (options_context_t): New member 'received_github_request_id_header'.
>> (capabilities_headers_iterator_callback): Check if we received that header.
>> (options_response_handler): Allow DAV responses without DAV headers, if
>> the 'X-GitHub-Request-Id' header is present.
>>
>> * subversion/tests/cmdline/dav_tests.py
>> (connect_to_github_server):
>> Remove the @XFail annotation. Add an @Issue annotation.
>> Change the test URL to point at HTTPd's GitHub mirror.
>>
>> Issue: SVN-4789
>> ]]]
> Actually the attached updated patch is a bit more to my taste.

This has been resolved by GitHub.

-- Brane
Received on 2018-12-19 00:53:23 CET

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

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