Hi Pavel,
On 5/24/2016 13:31, Pavel Lyalyakin wrote:
> Hello Stefan,
>
> On Mon, May 23, 2016 at 8:34 PM, Stefan <luke1410_at_posteo.de> wrote:
>> Hi Pavel,
>>
>> Thanks for the feedback.
>> Can't say I disagree with your statement that emphasizing on one
>> possible cause (and especially most likely not the most common one) for
>> a 400-error is not the best way to go.
>>
>> But as far as I'm concerned this is not how the section is phrased. The
>> first paragraph especially points to the server log as the first thing
>> to check to trace down the actual problem. The following section then
>> points to two known cases which can trigger the problem. I'd certainly
>> support extending the list with any further known case, and IMO the list
>> you provide is an absolutely reasonable extension to that list.
> While I don't like the idea of adding an entry about this error to the
> FAQ, I can think of this general advise for the users getting 400
> 'Bad request' errors:
> The very first recommendation has to be to contact the system
> administrator and trying the latest Subversion client. :) Further
> recommendations should be to take a look at the logs and to check the
> firewall, proxy and antivirus. Search the users@ mailing list or use
> the web search. If nothing helped, search the bug tracker.
>
> But in such case this is is not a Question - Answer FAQ format
> anymore.
This is such a generic/general suggestion which in theory would apply to
any issue, so that IMO this wouldn't be worth mentioning somewhere
explicitly other than on the reporting-issues page [1] where it is
already mentioned more or less. :-)
So IMO it would be better to not add anything to the FAQ page then for
the 400-error in this case.
>
>> Hence, if that's the main concern here, I'd certainly add the three
>> mentioned causes to that section then.
>>
>> To me the FAQ section seems to be the most reasonable place to add these
>> kind of known issues. IMO it's the location where someone who runs into
>> the problem is likely to look for a solution (if he bothers searching
>> for a solution at all, that is). Or would you suggest to put the
>> information in some other place?
> Merriam-Webster dictionary defines FAQ as
> [[[
> a document (as on a Web site) that provides answers to a list of
> typical questions that users might ask regarding a particular subject
> <check the FAQ>;
> ]]]
>
> FAQ should contain answers to *typical questions* and here are some of
> the good questions that are answered on SVN FAQ page:
> * I've started svnserve, but it doesn't seem to be listening on port
> 3690.
> https://subversion.apache.org/faq.html#svnserve-listen-host
> * I cannot see the log entry for the file I just committed. Why?
> https://subversion.apache.org/faq.html#hidden-log
> * Why does SVN log say "(no author)" for files committed or imported
> via Apache (ra_dav)?
> https://subversion.apache.org/faq.html#no-author
> * How can I specify a Windows drive letter in a file: URL?
> https://subversion.apache.org/faq.html#windows-drive-letter
> * How does Subversion handle binary files?
> https://subversion.apache.org/faq.html#binary-files
>
> All of these questions are typical IMO; and there is a clear question
> and it has a more or less clear answer. It's great to have these
> questions answered on the FAQ.
>
> But what about the entry about this 400 'Bad request' error? It does
> not seem to be typical or frequent enough and it has too many possible
> answers to provide a clear answer on how to solve the problem. You can
> provide some basic guidance on how to narrow down the issue,
> troubleshoot and identify the root cause. The steps for this are
> pretty the same as for troubleshooting any other network related
> problems.
You are making a good point about the issue not being reported frequent
enough and hence it doesn't quite deserve an entry on SVN's FAQ page.
For that one argument, I tend to agree with you.
For the other point I however still see it the other way around. Just
because an issue can have a variety of reasons/causes and solutions,
that fact alone doesn't exclude it IMO from being a good candidate to be
added to the FAQ list.
Still, your other argument kind of convinced me that in this case the
SVN FAQ might not be the most suitable place to document this issue group.
Hence, if nobody else brings up arguments for putting it onto the FAQ
page, I'll drop the matter here and thank you for your time discussing
the idea with me. :-)
To still get something out of that, I'm atm considering to write a quick
blog entry on my own blog and send a quick announcement to the SVN users
mailing list so just in case s/o runs into the problem, there's a chance
he can build upon the investigation work done here already. I'd really
much appreciate if you would review the blog post before I put it live,
so I can incorporate any feedback you might have beforehand. What do you
think?
>
>> Regarding the concern about tweaking the LimitRequestFieldSize. I could
>> certainly rephrase that section to emphasize that tweaking that value
>> should be done with care considering the security impact. But given that
>> you can run into an issue with the default limit here using SVN and it
>> seems that at least for the 1.9 branch there is not going to be a final
>> solution to completely prevent running into this situation, I really
>> think this should be mentioned/written down somewhere so its on record
>> and can be referenced for user support requests.
> Aren't you putting the cart before the horse? Can we call these
> SVN-4557 & SVN-4634 problems typical or frequent? I don't see that
> many reports of these problems. Moreover, SVN-4557 is now solved and
> I don't see any recommendation in SVN-4634 that the solution would be
> to advise any config customizations.
The recommendation for the LimitRquestFieldSize was based on the
statement from Bert in this post [2]: "The real fix for delete, replace,
etc. of trees with many locks is to somehow allow the headers to go
through, but this requires a config change from the admin." and Philip's
reference to that config setting in a comment [3] on SVN-4557.
>
>> Regarding the layout: Right. Will correct the layout in the next version
>> of the patch (assuming the usage of the line breaks rather than using
>> proper paragraph sections is the concern here).
>>
>> What do you think? Would rephrasing/extending the section solve the
>> concerns you have?
> I think that the the entry about 400 'Bad request' errors should not
> be on the FAQ. This is not a question that can be answered in clear
> manner. The topic is much broader and does not fit FAQ format.
>
> There may be other great places to publish troubleshooting guidance
> about this error in general, but the official Subversion FAQ is not
> one of them, IMO.
>
> This is a great idea to provide provide basic troubleshooting advise
> and tell about the cases when these problems can occur. But, again,
> I don't think that the official Subversion FAQ is the right place for
> this.
Agreed.
Regards,
Stefan
[1] https://subversion.apache.org/reporting-issues.html
[2]
http://mail-archives.apache.org/mod_mbox/subversion-dev/201605.mbox/%3C078c01d1a9d4%246b0add10%2441209730%24%40qqmail.nl%3E
[3]
https://issues.apache.org/jira/browse/SVN-4557?focusedCommentId=14932963&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14932963
Received on 2016-05-26 02:03:46 CEST