[Solved] Resource Save goes to 404 if Content Field contents "too long"

I run an established EVO website, running on 1.0.8 (since upgraded to 1.0.12). I had to make a minor change to a resources pagetitle field value. When I pressed Save, the site's 404 page was returned, and the edit was not accepted. Other pages on the same site were similarly edited, but all the saves were accepted.

I tried:
Changing nothing and saving as-is;
Changing the Alias and saving;
Checking the mySQL database table and repeating all the above;

Still the 404.

I upgraded to 1.0.12 (the last of many EVO sites to be so upgraded).

Same behaviour.

I deleted the resource, and rebuilt the resource from scratch, saving successfully after each field was added, leaving the content field until last.
I added the Content field's content and saved: 404
I added part of the Content field's content, paragraph by paragraph, saving after each addition. Fine. But when I got to about 3,000 characters of content, 404 again.

If I make changes directly into the mySQL database the edits are accepted and displayed correctly.

I checked the html being added as content and tried adding a liitle more of what had already been accepted in an earlier save. Again, rejected (or rather, a 404 was returned), as soon as the length grew to 3,000 characters of html.

A puzzler: I've not come across this phenomenon before. Has anyone else?

Any ideas generally?


Nic Boyde [ed. note: nicboyde last edited this post 12 years, 8 months ago.]

Mod_security (suhosin) can do this. Check with your hosting support about it. It may be a length issue, or it may be some specific text at that point that is being rejected. There may be other server settings to limit the size of the POST. Again, this is something your hosting support should know.

Susan

Thanks for the suggestions - I'm following up on MOD Security as a matter of course - I had a huge problem last year because my hosting firm had 'upgraded' something which brought down hundreds of their clients' sites.

But it doesn't quite explain why some longer pages save fine (which I have now established), nor why on this particular page it saves fine until I add in just one more ASCII character inside <p></p> tags.

Nor does it explain why this page was fine a few weeks ago, but broken now.

On the other hand, if my hosting firm has been up to its tricks again, and not telling me, (for which they have a certain amount of form) it might be Suhosin yet. Presumably set so as to object to quotes, double-quotes, slashes, backticks, tildes, ampersands and all Non-American characters for good measure.

Grrr.

I'll report.

Well, Susan, my hat off to you. Again.

My hosting company grovel at my feet: yes - they had "upgraded" MOD_Security and forgotten that I use MODx. (And forgotten to tell me, which I am less willing to forgive).

Let the Search Engines read: MODx+Manager+404 = MOD_Security cokc-up.

Thanks



Nic

This comes up whenever there's a js-heavy app like Ext JS because it passes so much info via long requests. But ultimately, it's laziness on the part of the hosting company because they are not looking more closely at what those files are. It's absolutely true that having exceedingly long lines of text is suspicious because it's a characteristic shared by many malicious payloads: the script contents are fuzzed and base-64 encoded to make them more difficult to locate via "grep" or other search utilities, so instead you search for any file that has really long lines and then review them to see if they are in fact malicious. It's a bit ludicrous to blacklist long lines entirely without further review because there are plenty of legitimate files and apps that rely on them, e.g. IonCube encrypts PHP scripts in ways that look a lot like malicious payloads and MODX compresses javascript into long lines. Mod Security does take a lot of careful tuning on any server, so your hosting company needs to be committed to tuning it, and unfortunately, they can't do that for every use-case without a lot of user feedback. Sometimes you can avoid running into trouble by disabling JS compression in the MODX manager, but really what would help would be if there were a published set of rules for mod_security for compatibility with MODX -- it's a bit of a tall order since MODX has configurable urls...