3

It's my first post/thread here, I haven't been active in forums for some time cause frankly I didn't need it, but this one just got me. I tried everything in my knowledge -and I mean everything, I'm a fanatic trial-and-error tester.

Situation: jQuery, posts some data through Ajax collected primarily from a $('#textarea') to a php file on server. If the data is >X Bytes, I get 404 Not Found and the 404 Html page in Ajax error handler. Otherwise, everything runs smoothly and I get my results.

I must specify that I post to a php file that loads Wordpress's wp-blog-header.php before doing calculations, as the code is intended to be part of a WPplugin.

  • I tried to return header("HTTP/1.1 200 OK") as some suggested, considering WP was altering the header for not finding the file as part of the system, and it solved the issue locally for some cases, but not remotly.
  • I tried to set the Content-Length in ajax call.
  • I switched between the WP type of handling Ajax calls, and having my own .php file, in the folder of my plugin.
  • I alternated calling wp-load.php, wp-config.php, and wp-blog-header.php in the beginning of my ajax file, and still nothing (solved some issues locally, but not remotely) Nothing worked. The only thing that works is trimming the content sent to the .php file. 2000-2500B work ok, 3000+B give me 404 not found.

What could this be? post_data_size is 8M on server. Could this be maybe related to SSL as I've seen in some cases? Is this server-side? Please help,

P.S. My Javascript:

var data1 = {
    action: 'get-tables',
    html: $('#content').val(),
    nonce: kwd_settings.nonce
};
$.ajax({
    url: kwd_settings.ajax_url,
    type: 'POST',
    data: data1,
    scriptCharset: 'utf-8',
    timeout: 10000, /*10 seconds*/
    beforeSend: function( xhr ) {
        xhr.setRequestHeader("Content-length", $('#content').val().length+500);
        showProgress(true);
    },
    error: function (request, ajaxOptions, thrownError) {
        alert(request.statusText);
        alert(request.responseText);
        showProgress(false);
    },
    success: function( response ) {
        var r= response;
        showResponse(r);
    }
});
Catalin
  • 121
  • 1
  • 9
  • Can you post successfully a regular HTML form with a 4000B+ textarea? – Álvaro González Nov 15 '11 at 11:04
  • Just tried it, no, gives 404 error. This is getting interesting. The url becomes the correct kwd-ajax.php, but displays the 404 error page. So I guess it's not an ajax thing after all, but a Post thing. IF I replace the text with something short, it's ok. – Catalin Nov 18 '11 at 11:46
  • Ok: just posted a long 28.000 chars text, and came back with no error. I think my algo is a memory hog or something, I use an htmlTools class that is allocating a lot of memory structures. Will have to move to PHP DOM parsing functions. – Catalin Nov 18 '11 at 11:49
  • Even more: there was ONE PHRASE in the text that was triggering the crash, so it's algorithmic fault... will get to it. Thanks guys for your help :) – Catalin Nov 18 '11 at 11:53
  • Guys, this must be twilight zone: the words creating the problem are these: "You will basically create". I emptied the ajax file to nothing but an echo "here". When I let these 2 words in the body, it gives me Internal Server Error (moved to a new testing server). When I cancel them, it displays "here". This is unreal... have you every encountered such behaviour? – Catalin Nov 18 '11 at 13:38

3 Answers3

1

I know this is an old question, but since there was no solution, and I literally just found the solution to this myself (took me an entire day of trouble-shooting), I figured it is worth posting. The problem was the default "Request Filtering" option in IIS. I had to open the "Request Filtering" screen and click "Edit Feature Setting" (at the right side of the screen) and changed the Maximum allowed content length, Maximum URL length, and Maximum query string length to an amount that would allow my posts. I then restarted IIS and the ERROR 404's stopped and my posts completed :-)

I could not find this answer anywhere on the web, for some reason.

GeoCoder
  • 11
  • 1
  • 1
    The only problem is, he is using Apache and you are talking about IIS. So it is not solution for his problem. – shaggy Apr 29 '17 at 13:11
0

Try setting:

xhr.setRequestHeader("Content-length", 0);
Brock Adams
  • 90,639
  • 22
  • 233
  • 295
  • Tried it. Same response, Ajax error and 404. The response I see in console is "Refused to set unsafe header "Content-length"" – Catalin Nov 16 '11 at 12:58
  • OK, the server won't let you set an undefined length. You may want to take a look at this: http://stackoverflow.com/questions/5515869/string-length-in-bytes-in-javascript. – matthijs koevoets Nov 17 '11 at 15:03
0

Given the symptoms you've described in further comments:

  1. Simple regular POST fails as well.
  2. Failure depends on precise data content rather that raw size.
  3. Strings that contain create trigger the issue, suggesting an attempt to prevent damage through SQL injection.

... I'd find out whether your hosting service has some sort of security module installed, such as mod_security or Suhosin. So far, it's the most likely suspect.

Álvaro González
  • 142,137
  • 41
  • 261
  • 360
  • Yes, I guess so: also cancelling only the word CREATE from that phrase triggers the error. However, I has already disabled mod_security with SecFilterEngine Off SecFilterScanPOST Off in .htaccess, and still nothing. So I guess AllowOverride is set to Off? This I don't know, I have no access to server settings... any idea why .htaccess is not disabling mod_security? – Catalin Nov 18 '11 at 17:13
  • @Catalin - Perhaps mod_security isn't installed or SecFilterScanPOST is not allowed in `.htaccess` (whatever, I can't find it in the [documentation](http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecRequestBodyAccess)). – Álvaro González Nov 18 '11 at 17:50
  • I wonder: how do people programming lots of javascript protect against this kind of issues? It feels like it's too vulnerable, and so easy to NOT work on some configurations. Since this is supposed to be a commercial product, how can I protect against my clients having all sorts of configs? Do you think base64-encoding the text before POST-ing it is a solution? – Catalin Nov 18 '11 at 21:30
  • Believe me, there's no limit on how misconfigured a server can be. I suppose we all add specific workarounds as issues arise. – Álvaro González Nov 19 '11 at 12:40
  • Sorry for resurrecting this post, in the end I base64'd the content. I have a question though: how can wordpress post the same content, on the same server, and have it work? How could they program it (maybe wp tweaks the content before posting??) so as to surpass all server limitations? Maybe I could apply the same tecnique – Catalin Nov 25 '11 at 13:05