You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan <lu...@gmx.de> on 2016/05/15 00:00:53 UTC
[PATCH] add FAQ section about "bad request" errors
Hi,
following patch adds a new entry to the FAQ's trouble shooting section,
documenting the known problem with large headers, exceeding Apache
httpd's LimitRequestFieldSize setting.
[[[
Document known issue about long header sections causing problems with
Apache httpd.
* docs/faq.html
(Table of Contents): add link to new http-400 section
(http-400): new trouble shooting section about http-400-error
]]]
Regards,
Stefan
Re: [PATCH] add FAQ section about "bad request" errors
Posted by Pavel Lyalyakin <pa...@visualsvn.com>.
Hello Stefan,
On Thu, May 26, 2016 at 3:03 AM, Stefan <lu...@posteo.de> wrote:
> Hi Pavel,
>
> 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?
>
Sure, I would be glad to help. This approach looks great!
>
> 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.
>
Thanks for pointing me to these statements. Note that Bert tells that this
kind of locking causing the errors is kind of (very) unexpected scenario,
and it's still unclear why some users try to lock large sets of repository
items.
--
With best regards,
Pavel Lyalyakin
VisualSVN Team
Re: [PATCH] add FAQ section about "bad request" errors
Posted by Stefan <lu...@posteo.de>.
Hi Pavel,
On 5/24/2016 13:31, Pavel Lyalyakin wrote:
> Hello Stefan,
>
> On Mon, May 23, 2016 at 8:34 PM, Stefan <lu...@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
Re: [PATCH] add FAQ section about "bad request" errors
Posted by Pavel Lyalyakin <pa...@visualsvn.com>.
Hello Stefan,
On Mon, May 23, 2016 at 8:34 PM, Stefan <lu...@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.
> 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.
> 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.
> 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.
--
With best regards,
Pavel Lyalyakin
VisualSVN Team
Re: [PATCH] add FAQ section about "bad request" errors
Posted by Stefan <lu...@posteo.de>.
Hi Pavel,
> Hello,
>
> On Fri, May 20, 2016 at 10:50 PM, Stefan <lu...@posteo.de> wrote:
>> On 5/15/2016 02:00, Stefan wrote:
>>> Hi,
>>>
>>>
>>> following patch adds a new entry to the FAQ's trouble shooting
>>> section, documenting the known problem with large headers, exceeding
>>> Apache httpd's LimitRequestFieldSize setting.
>>>
>>> [[[
>>> Document known issue about long header sections causing problems with
>>> Apache httpd.
>>>
>>> * docs/faq.html
>>> (Table of Contents): add link to new http-400 section
>>> (http-400): new trouble shooting section about http-400-error
>>> ]]]
>> Anybody feels like approving the change? Or is there anything I should
>> improve in the patch before committing it?
> This error can have different causes and that's why you should not put
> an emphasis on some of them, while omitting other causes. And I don't
> think that the entry on troubleshooting 400 'Bad Request' errors fits
> FAQ format. There can be too many answers to the question "How can I
> resolve it?". This error does not give enough information to provide a
> reader with instructions on how to resolve it.
>
> I mean that it is possible to get 400 'Bad request' error in numerous
> other cases and pointing out just some of them on the FAQ page is not
> the best idea. IMO, such FAQ entry can distract a reader from
> identifying the real root cause of the problem. Just to name a couple
> of additional examples when you can get 400 'Bad request' error:
>
> * Unlocking a file with a stolen lock will result in 400 'Bad request'
> error. This problem is described in SVN-4372[1].
>
> * Authenticating to the server using Negotiate/Kerberos when the
> particular user who's accessing the repository is a member of too
> many groups or has enormous SID history will result in 400
> 'Bad request' error. This problem is described in the article
> "HTTP status 400 Bad Request error when a user connects to VisualSVN
> Server"[2].
>
> And don't forget that an antivirus, active firewall or proxy server
> can be the root cause as well[3].
>
> BTW, the request field size limit should usually be between 8-16KB and
> configuring it to be less can lead to getting 400 'Bad Headers' errors
> too. On the other hand, configuring it to be larger than 16KB can be
> bad from security and performance point of view. Therefore, you should
> avoid telling the reader to change the limit without considering his
> particular case.
>
> That said, I think that this FAQ entry will confuse the reader rather
> than help him to identify the root cause and resolve it. It'd be
> better to mention that the problem can have a lot of various causes
> and the reader has to check the server logs for clues. As always, it
> makes sense to recommend using the latest Subversion version and
> advise searching the Apache Subversion bug tracker for "Bad request"
> errors. Checking antivirus, firewall and proxy is also recommended. If
> nothing of this helped, contact users@ Subversion for help.
>
> But these basic recommendations can be applied to the troubleshooting
> of practically any generic error. That's why I don't think that 400
> 'Bad Request' needs a special entry in the FAQ.
>
> [1]: https://issues.apache.org/jira/browse/SVN-4372
> [2]: https://www.visualsvn.com/support/topic/00098/
> [3]: https://mail-archives.apache.org/mod_mbox/subversion-users/201108.mbox/%3CCALb=wn=wuWkR392eyoLP0F5E8b-k2vnE1bTU5LGVtUOEGoD8Og@mail.gmail.com%3E
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.
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?
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.
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?
Regards,
Stefan
Re: [PATCH] add FAQ section about "bad request" errors
Posted by Pavel Lyalyakin <pa...@visualsvn.com>.
Hello,
On Fri, May 20, 2016 at 10:50 PM, Stefan <lu...@posteo.de> wrote:
>
> On 5/15/2016 02:00, Stefan wrote:
> > Hi,
> >
> >
> > following patch adds a new entry to the FAQ's trouble shooting
> > section, documenting the known problem with large headers, exceeding
> > Apache httpd's LimitRequestFieldSize setting.
> >
> > [[[
> > Document known issue about long header sections causing problems with
> > Apache httpd.
> >
> > * docs/faq.html
> > (Table of Contents): add link to new http-400 section
> > (http-400): new trouble shooting section about http-400-error
> > ]]]
> Anybody feels like approving the change? Or is there anything I should
> improve in the patch before committing it?
This error can have different causes and that's why you should not put
an emphasis on some of them, while omitting other causes. And I don't
think that the entry on troubleshooting 400 'Bad Request' errors fits
FAQ format. There can be too many answers to the question "How can I
resolve it?". This error does not give enough information to provide a
reader with instructions on how to resolve it.
I mean that it is possible to get 400 'Bad request' error in numerous
other cases and pointing out just some of them on the FAQ page is not
the best idea. IMO, such FAQ entry can distract a reader from
identifying the real root cause of the problem. Just to name a couple
of additional examples when you can get 400 'Bad request' error:
* Unlocking a file with a stolen lock will result in 400 'Bad request'
error. This problem is described in SVN-4372[1].
* Authenticating to the server using Negotiate/Kerberos when the
particular user who's accessing the repository is a member of too
many groups or has enormous SID history will result in 400
'Bad request' error. This problem is described in the article
"HTTP status 400 Bad Request error when a user connects to VisualSVN
Server"[2].
And don't forget that an antivirus, active firewall or proxy server
can be the root cause as well[3].
BTW, the request field size limit should usually be between 8-16KB and
configuring it to be less can lead to getting 400 'Bad Headers' errors
too. On the other hand, configuring it to be larger than 16KB can be
bad from security and performance point of view. Therefore, you should
avoid telling the reader to change the limit without considering his
particular case.
That said, I think that this FAQ entry will confuse the reader rather
than help him to identify the root cause and resolve it. It'd be
better to mention that the problem can have a lot of various causes
and the reader has to check the server logs for clues. As always, it
makes sense to recommend using the latest Subversion version and
advise searching the Apache Subversion bug tracker for "Bad request"
errors. Checking antivirus, firewall and proxy is also recommended. If
nothing of this helped, contact users@ Subversion for help.
But these basic recommendations can be applied to the troubleshooting
of practically any generic error. That's why I don't think that 400
'Bad Request' needs a special entry in the FAQ.
[1]: https://issues.apache.org/jira/browse/SVN-4372
[2]: https://www.visualsvn.com/support/topic/00098/
[3]: https://mail-archives.apache.org/mod_mbox/subversion-users/201108.mbox/%3CCALb=wn=wuWkR392eyoLP0F5E8b-k2vnE1bTU5LGVtUOEGoD8Og@mail.gmail.com%3E
--
With best regards,
Pavel Lyalyakin
VisualSVN Team
Re: [PATCH] add FAQ section about "bad request" errors
Posted by Stefan <lu...@posteo.de>.
On 5/15/2016 02:00, Stefan wrote:
> Hi,
>
>
> following patch adds a new entry to the FAQ's trouble shooting
> section, documenting the known problem with large headers, exceeding
> Apache httpd's LimitRequestFieldSize setting.
>
> [[[
> Document known issue about long header sections causing problems with
> Apache httpd.
>
> * docs/faq.html
> (Table of Contents): add link to new http-400 section
> (http-400): new trouble shooting section about http-400-error
> ]]]
Anybody feels like approving the change? Or is there anything I should
improve in the patch before committing it?
Regards,
Stefan