> Am 06.11.2018 um 01:57 schrieb Daniel Shahaf <d...@daniel.shahaf.name>: > > Dr. Rolf Jansen wrote on Tue, 06 Nov 2018 00:27 -0200: >> FYI, RFC 2518 has been obsoleted since 11 years by RFC 4918, and the >> relevant chapter moved to 10.1: >> https://tools.ietf.org/html/rfc4918#section-10.1, and yes there is still >> written "the DAV server MUST return the DAV header". However, the RFC >> does not require the DAV client to bail out if the server fails to do >> so, this was your choice. > > There are two schools of thought: one, "be strict in what you send and > lenient in what you accept"; two, "be strict in what you send and strict > in what you accept". This list is not a good place to have > a discussion about which one is better in general.
Of course, this is the choice of the subversion team as well. However, if you want to be taken serious on the second option then it would be better not to refer to a RFC which is outdated for 11 years, even if particularly not much changed. Read „having an issue with the Robustness principle“ means that you generally don’t adhere with it, it does not imply that it would be good to adhere to - as said already, your choice. I wrote a closed source Web/DAV server in C and I do like the principle. > Instead, let's focus on > the specific problem at hand. If you have an idea for how we might continue > operating with GitHub without regressing the failure mode that that error > message was added to fix, we’re all ears. I came in here only because the FreeBSD port maintainer of Subversion told me to report my problem here. I came in late, others saw the same problem already. What I learned from that other thread is that somebody complained about the „misleading“ error message „Malformed XML in response,“ when pointing SVN to a plain web server, one which does not serve a SVN repository. For a DAV noob, this error message is IMHO indeed not very helpful. You need to know that DAV is heavily based on XML. However, I have my doubts, that the other message „does not support the HTTP/DAV protocol“ is much more helpful to a SVN noob, because you need to know that in the given respect SVN is utilizing the DAV protocol. So far to the term non-solution. Complex, because this was not achieved by simply rephrasing the misleading error message, but by adding another obstacle into the connection protocol and throwing a new message if somebody stumbles across. Now in regards to the term non-problem. Misspelling of URL’s may happen to everybody, not only to noobs, and yes, I saw this „Malformed XML in response,“ in the past, I corrected the URL, pronto. Said all this, I would have simply amended this error message by a hint. „... check the URL is pointing to a SVN repository!“. > The obvious idea is to wait a few days for GitHub to make the one-line > change to their server code which will fix the issue. Well, I am able to wait. I placed temporary patches into the subversion port directories of my FreeBSD systems, and when a new Subversion comes out these will be removed automatically. Best regards Rolf
