Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#10675 closed defect (bug) (invalid)

Error 403 when editing post which has 74 revisions

Reported by: pavelevap Owned by:
Milestone: Priority: high
Severity: normal Version: 2.8.4
Component: Revisions Keywords: Revisions, 403 error
Focuses: Cc:


When I try to edit and update post which has exactly 74 saved revisions, then there is 403 error from webserver and post is not updated. All other posts working, but everytime there is 74 revisions, I can not save this post.

Change History (10)

#1 @ramoonus
9 years ago

I think this has to do with php memory limits what version of php are you using? whats your servers memory limit? how much memory are you using on the dashboard?

#2 @pavelevap
9 years ago

I deleted all revisions and turn them off, but posts which had 74 revisions before can not be updated. There is 403 webserver error...

I think it is not related with PHP memory: Memory Overview PHP Version : 5.2.6-0.1~lenny1 / 32Bit OS Memory limit : 300 MByte Memory usage : 22.22 MByte

I will try to get logs from my webhoster and post here additional info...

#3 @rudolflai
9 years ago

I think you cannot justify that this is an issue, unless posts with more than/less than 74 revisions work, but posts with EXACTLY 74 revisions don't work.

#4 @pavelevap
9 years ago

Yes, posts with EXACTLY 74 do not work and so there are no posts with more than 74 revisions (because posts with 74 revisions can not be updated). All other posts with less than 74 revisions works well... Except posts which had 74 revisions and I deleted some of these revisions because I wanted to try if it works when I delete some of them... It is very strange...

#5 @mrmist
9 years ago

This is probably a security module on your hosting that's interfering with the site. Do you run mod security?

I've just pushed through about 80 revisions on my test site, no 403.

#6 @pavelevap
9 years ago

So, I received logs from my webhoster and I found 403 errors (really based on security module):

[Sun Aug 23 19:09:36 2009] [error] [client] ModSecurity: Access denied with code 403 (phase 2). Operator GT matched 500 at ARGS. [file "/etc/apache2/conf.d/modsecurity_crs_23_request_limits.conf"] [line "28"] [id "960335"] [msg "Too many arguments in request"] [severity "WARNING"] [hostname "www.domain.com"] [uri "/wp-admin/post.php"] [unique_id "SpF30H8AAQEAACpH9m8AAAAM"]

So, it is problem of WordPress or my webhoster? What should I tell my webhoster to do to working properly? But why it does not work only when there are 74 revisions? Thank you very much...

#7 @rudolflai
9 years ago

I think this confirms that its a restriction of the host. Not a problem of Wordpress.

#8 @pavelevap
9 years ago

Yes, it looks like, but why in this case? Is there any hidden WordPress bug which can be seen only with higher number of revisions ("Too many arguments in request")? Mod security is used by many webhosters and WordPress should handle with it correctly...

#9 @dd32
9 years ago

Can you provide the URL (You may blank out your domain if needed) of the page that 403's?

Too many arguments in request

That seems to be suggesting that theres ?a=b&c=d....Z=z etc.. A really stupid mod_security rule IMO, and i doubt most other hosts have that rule enabled (Its entirely up to the host as to what rules they run, or how recent the rules they run are)

Bw warned however.. Sometimes.. Theres absolutely no way around mod_security (In the past, A bug was fixed with it, by changing a lable from "Do it" to "Upload now" (ok, i cant remember the exact strings, But just by changign the label on a button everything worked fine))

#10 @azaozz
9 years ago

  • Milestone 2.9 deleted
  • Resolution set to invalid
  • Status changed from new to closed

Agree with dd32 it's a strange ModSecurity rule, don't see what we can do about it... Seems the best option is to contact the hosting company and ask them either to rise that number or remove it. Alternatively delete some unneeded revisions (with a plugin) and set define('WP_POST_REVISIONS', 50); in wp-config.php so you don't exceed the limitation.

Note: See TracTickets for help on using tickets.