Last modified: 2013-10-30 17:29:39 UTC
Often, but not always, when submitting an edited page via "Save page" or "Show preview", there will be a delay of around 10 seconds, followed by a 400 Bad Request. When this happens, hitting back on my browser and resubmitting INVARIABLY results in the edit being accepted. I've used LiveHTTPHeaders to verify that the headers and POST data sent in both cases are IDENTICAL, except for the multipart boundaries. I've previously posted a snippet of my access and error logs in #mediawiki for such an HTTP transaction: http://dpaste.org/MhTU/ (which will expire on 3/8/11). Added: And would you believe that the first time I submitted this bug, I got the same problem: A 400 Bad request (around 9:27 am PST, 2/28/11).
Some further checking reveals a pattern of 400 errors using Firefox on some sites by a number of users. Suggestions to fix the problem include clearing the cache and cookies, which work for some, although for Mediawiki, that would bypass the session and require me to log in, which has never been a problem. (My 400s only come during Save/Preview.) So, maybe something to do with the way cookies are being set? Or maybe a bug in Firefox? (I'm using 3.6.13.)
Created attachment 8222 [details] Contents of http://dpaste.org/MhTU/ This seems like it could be caused by a Firefox extension. What do you have installed?
Created attachment 8224 [details] List of firefox extensions
It looks like you might also try setting up a new profile. http://the-edmeister.home.comcast.net/~the-edmeister/tips-html/tips-restoring_your_browsing_data.html http://frankkoehl.com/2009/04/fixing-firefox-gmail-400-bad-request/ Maybe you can use the CLI sqlite utility to test your cookies file?
I've looked at the cookie database (I use sqlitebrowser instead of the CLI), and didn't see anything unusual, although I'm not sure what I'm looking for. Before I go recreating my whole profile, I wonder what the explanation might be for one aspect of my experience, noted in the original report: after getting a 400, clicking "Back" on my browser and resubmitting INVARIABLY results in success, even though the headers (including cookies) and posted data are identical, as reported by LiveHTTPHeaders.
re sqlite use: use the browser to backup/dump the database and remove your profile (after assuring yourself that you can recreate it using the backup). After you remove the profile, try to reproduce the error. If it doesn't show up, it is the fault of the profile. If it shows up with a new profile, well, then we have a real bug.
Todd: Is this still an issue? Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems. It does not disable plugins which are add-ons.) See http://support.mozilla.com/en-US/kb/Safe+Mode And does this also happen with a new and empty profile? See http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-profile and http://support.mozilla.org/kb/Managing%20profiles . If you still see this problem in the new profile, please enter the address "about:support" in the address bar and attach (using the "Add an attachment" link above) the output for your original profile (not the new profile), as the "Modified Preferences" section could be interesting. Thanks for your help!
Unfortunately closing this report as no further information has been provided. Todd: Please feel free to reopen this report if you can provide the information asked for in comment 7, and if this still happens in a recent and supported MediaWiki version. Thanks!
Sorry, I had forgotten about my bug report and, in the meantime, switched to Chromium, where I haven't had the problem. If others develops the problem on Firefox and find this, then perhaps they will be led to try the "remove profile" solution themselves and report. Thanks!
