Last modified: 2012-12-08 08:39:39 UTC
Hi, When you check many boxes in an article's history (400 ~ 500) to hide them at once, you get the Wikimedia Foundation error message : « Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes. » This is because there are many input fields in the deletion form (one checkbox per revision), and the form action is GET instead of POST. This results in a 414 Request-URI Too Long (the URL looks like […]&ids[66828215]=1&ids[67221904]=1&ids[67221237]=1&ids[67218262]=1&ids[62079400]=1&ids[62078441]=1&ids[65037145]=1&ids[58535470]=1[…]). I don't know how we could fix this, because using POST instead of GET would prevent users from linking to diff and deletion pages — I'm pretty sure we don't want this. Best regards,
We could probably make the form a POST and have the action URL to be able to react to both POST and GET
(In reply to comment #1) > We could probably make the form a POST and have the action URL to be able to > react to both POST and GET The main issue I see with this solution is that it's the same form which is used for diffs. While I don't think many people link to deletion pages, people often link to diff pages, and not having the parameters in the URL to copy-paste (even if GET is supported) would IMHO be an even bigger problem than the 414 error (which only affects users with sysop / oversight rights, under unusual circumstances). And what is more, this would break the navigation in the history, since modern browsers ask the user for the POST data to be sent again. Having two forms (one for diffs and one for deletion) would make sense (as there are separate submit buttons and unrelated input forms), and we could have the diff form using GET and the deletion form using POST. Unfortunately, I don't think it's possible to interweave forms in HTML… Thanks!
Setting Lowest minor (and could be considered an enhancement) because revdel can't really be *expected* to work with several hundreds or thousands of revisions at once, and there's no substantial reduction of functionality because one can just split the job in multiple steps. Note that such bug revdeletions are sometimes attempted to circumvent the bigdeletion limit, which is another not so bright idea.
