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? > - 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). 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. 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. > 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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
