0

I have a Javascript client which is using JQuery to send Ajax POST requests to my PHP code on a shared Hostgator server. The post data is a few hundred KB of JSON data which is read using file_get_contents('php://input'). The PHP post data limit is reported as 64 MB, and normally everything works fine.

But every few days the PHP code is called with an illegal JSON string, and the client receives a status of 400. Presumably this status comes automatically from Apache, as my code is not doing anything special to send it. Yesterday I put code in place to log the post data, and it is truncated JSON of length 196,269...suspiciously just under 3 * 64KB.

It seems like the request is being truncated; since I see this from only one of many clients, I can imagine that there is some intermittent network connectivity issue. If this is a bad conclusion, I'd be happy for someone to correct me, but please note that this is not what I'm asking about.

What I don't understand is why the PHP code is being called in this case. Shouldn't Apache not call when a malformed request is received? It's not possible that Apache starts the PHP execution before the full request, including post data, is received, and doesn't learn that there's a problem until after the PHP code is running, is it? If this is the expected behavior, how can my PHP code detect that this is a malformed request? Currently I'm relying on checking for errors from json_decode, but this seems imperfect, e.g. if the data was something other than JSON. I'm putting in code to check http_response_code(), but my reading of the PHP documentation makes me suspect that this will return 200:

If response_code is not provided, then the current status code will be returned. Both of these values will default to a 200 status code if used in a web server environment.

I'd be happy just to be pointed at Apache/PHP documentation that describes how error cases such as this are handled; my searches of the online documentation haven't been successful.

Thanks much for any help.

EDIT: I was asked to show I am sending the data; it is as shown below. But again, by question is not about how to AVOID the error (I am reasonably sure that it is a connectivity problem), but what happens in the PRESENCE of the error.

  $.ajax({
    url: myurl,
    xhrFields: {'withCredentials': true}, // Send credentials to the server to allow CORS
    dataType: 'json',
    contentType: 'application/json; charset=utf-8',
    type: 'POST', // Means that this changes server state (i.e. not cachable) and needed to send large amounts of data
    data: JSON.stringify(dataToSend),
    timeout: 120000,
    async: true,
    success: syncStepSucc,
    error: syncAjaxErr
  } );

EDIT: PLEASE NOTE that I am trying to understand the interaction between Apache and PHP when garbled/truncated data is received by Apache, and Apache decides to return HTTP status 400. The post data limit is 64 MB, well over the 196 KB that was received.

sferrari
  • 343
  • 2
  • 13
  • Start by looking at `post_max_size` your `php.ini` – RiggsFolly Dec 20 '16 at 09:59
  • Have you also checked `max_input_vars` – RiggsFolly Dec 20 '16 at 12:01
  • That's what I meant by "PHP post data limit". It is 64M. Also, while I appreciate tips to understandy **why** the post data is truncated, my question is really about PHP **recognizing that** the post data is truncated and reacting appropriately to it. – sferrari Dec 20 '16 at 12:02
  • 1000, but also unrelated: I'm not using the PHP $_POST or $_REQUEST variables, but rather php://input, as described. (I wish stackoverflow would allow noobies like myself to at least edit our own comments.) – sferrari Dec 20 '16 at 12:20
  • How are you sending this data from the browser, some code might allow us some insite to this issue – RiggsFolly Dec 20 '16 at 13:14
  • see http://stackoverflow.com/a/6135485/1288121 – mopsyd Dec 21 '16 at 18:32
  • Possible duplicate of [Increasing the maximum post size](http://stackoverflow.com/questions/6135427/increasing-the-maximum-post-size) – mopsyd Dec 21 '16 at 18:33
  • No: As I said in the original post, the post size is 64 MB and I received 196 KB. – sferrari Dec 21 '16 at 21:03
  • check apache logs too, error 400 is actually quite vague – Sebas Dec 21 '16 at 21:33
  • I have changed the title and edited the question slightly to try to make it as clear as possible what I am asking, which is NOT "why is my post data truncated". – sferrari Dec 22 '16 at 11:24
  • "intermittent network connectivity issue" - nope. TCP ensures that the data is received completely and in the original order. If some of the data was lost, the connection would be closed and you would not see any response from the webserver. – symcbean Dec 22 '16 at 14:17
  • ...and you might want to check how much data your webserver will accept - LimitRequestBody in Apache – symcbean Dec 22 '16 at 14:23
  • You're right, "intermittent network connectivity" is not correct. I really mean that there is something intermittently preventing the data that is being generated by the client from being received through Apache, but I have no idea where that might be...nor do I care. – sferrari Dec 22 '16 at 16:26
  • I'm sure LimitRequestBody is not the cause of the truncation: This exact code typically processes much larger requests successfully. But temporarily setting LimitRequestBody very low (3000) as a test was interesting: The PHP code ran, received zero bytes through `file_get_contents('php://input')`, and Apache returned STATUS 413 to the client. This is very much like the actual situation I am trying to understand: Apache detects an error, calls PHP, and returns a 4xx STATUS. Now, **how can my PHP code detect that Apache is doing this?** – sferrari Dec 22 '16 at 16:32
  • My question is similar to this one: http://stackoverflow.com/questions/2133652/how-to-gracefully-handle-files-that-exceed-phps-post-max-size As with that question, it's not about preventing the error but detecting it. However, the approach used to solve that problem is to roughly reproduce the checks that Apache performed, which I don't think is possible for my situation. – sferrari Dec 22 '16 at 16:48

0 Answers0