Hi Pavel,
> Hello,
>
> On Fri, May 20, 2016 at 10:50 PM, Stefan <luke1410_at_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
Received on 2016-05-23 19:35:07 CEST