Bug#677086: apache2-mpm-prefork: apache2 sends "400 bad request" on POST from some firefox browsers
-----Ursprüngliche Nachricht-----
Von: Stefan Fritsch <sf@sfritsch.de>
Gesendet: Montag, 11. Juni 2012 21:08
An: Thomas Voelkl <thomas@puzzleandplay.de>, 677086@bugs.debian.org
Betreff: Re: Bug#677086: apache2-mpm-prefork: apache2 sends "400 bad request" on POST from some firefox browsers
On Monday 11 June 2012, Thomas Voelkl wrote:
Affected Webservers/Operating Systems (server side):
- only apache<= 2.2.16 (squeeze) seems to be affected. (Apache
2.2.9, Debian; Apache 2.2.10, SUSE)
You mean that this problem also occurs with 2.2.9?
I did not test 2.2.9 by myself but a user reported problems on sites
with 2.2.9 running as follows:
"file uploaded => no response; file uploaded => no more actions
possible" There is a good chance that this is not the same problem.
- the affected clients also have this problem when uploading a file
to other companies webservers (if they are<= apache 2.2.16)
- apache 2.2.22 (wheezy) seems to work correctly.
- nginx, IIS also worked correctly
I installed a server for TESTING and run tshark to capture the
packets. - http://uploadtest.puzzleandplay.de/goodrequest.png
(upload a small file, it works)
- http://uploadtest.puzzleandplay.de/badrequest.png (upload a large
file, it did NOT work)
You marked a 20s interval there which rings a bell: The default
minimum timeout for reading the request headers is 20s (see
/etc/apache2/mods-enabled/reqtimeout.conf).
Yes, the reqtimeout.conf on my test system includes the default value:
RequestReadTimeout header=20-40,minrate=500
If the clients' virus
scanner needs more time before it sends the first bytes of the
request, it may be possible that mod_reqtimeout triggers.
I don't think so. A file size of 480K (see also the information on file
size later in this mail) is enough to get that bad request. But 480K (of
random data) is not so much that a virus scanner needs more than 20s to
do the scan. But you are right with "before it sends the first bytes".
The capture shows that the client is not sending any data before the
server answers with "bad request". And remember the behavior when using
firefox without plugins: In the reported cases then the uploads worked.
Additionally, when leaving the browser as it is and using only apache
2.2.22 instead, the capture shows, that the browser begins immediately
with sending data.
There is a bug that was fixed in 2.2.18 that read timeouts are
reported as status 400 and not 408 as they should.
But this does not fit earlier versions than squeeze because
mod_reqtimeout was only introduced in 2.2.15 (well, Ubuntu has it
backported to 2.2.14, I think).
Did you use loglevel debug in your test server? I would hope that at
level debug you should get some log message what went wrong.
I will check that entries asap.
Related (known) Problems did not help to solve the problem:
-
http://stackoverflow.com/questions/9921052/400-bad-request-when-up
loading-a -file-from-firefox-11-mac-osx
The bug mentioned there was fixed in Debian in 2.2.16-1.
Here is a wireshark capture file with testdata from apache 2.2.16:
http://uploadtest.puzzleandplay.de/capture-a2-2-16-100K-200K-512K-1M.cap
It includes 4 Tests. An affected firefox browser uploaded testfiles with
100K, 200K, 512K and 1M filesize. 100K and 200K works, 512K and 1M
failed with error "400 bad request". More detailled tests showed that
files <=475K work and files >=480K do not.
As already mentioned, the same tests after an upgrade to 2.2.22 works fine.
Reply to: