POST/Request Limits?

Getting "client denied by server configuration" log errors

[thinkcl]

Hi - first time posting here.

I have a desktop app I am building in Objective-C. It sends HTTP Post requests to an Apache web server where a PHP file handles the POST parameters and returns an XML document. I have been using Apache 2.0 & PHP 5 on my local machine for the last year and all is well - pretty much default config/ini files for both work great.

Yesterday I uploaded the necessary MySQL DB and PHP file to my hosting company so I could see what performance is like over the internet. Everything connected fine but while the app was loading one of it's more complex data objects I started receiving errors. I tracked it down to the Apache Error Log where I found...

client denied by server configuration: /the-path/the-file.php

This object model is making 12 synchronous (this important to note - the requests are NOT asyncronous) POST requests in a row to the same URL to load its data. To debug I put a sleep(1); function in my PHP file to slow down file execution to 1 second per request... this fixed the problem - everything loads fine... it just takes 12 seconds to load the model. Obviously the app is sending the POST requests so fast one after the other that Apache is reaching some sort of limit. In the near future I'll be optimizing my apps code to roll the 12 POST requests into one, but I am still want to solve this problem.

What Apache directives put a limit on requests per IP or requests per second? I am hoping I can change them via an htaccess file. Thanks in advance.

[jdMorgan]

Not sure about this one, but since an HTTP POST likely ends up being a "file write" function, and any given file can only be opened for writing by one process at a time, it may be that the "write lock" on the file from the first POST is not being handled properly by the script, or by PHP, or even by the OS when the second POST is attempted.

I'd suggest digging around to see if there are any additional log files (e.g. PHP errors, etc.) that provide more useful information. It could be something as simple as a write timeout returning a 403-Forbidden instead of the proper 503-Service Unavailable response (along with a Retry-After header).

If this becomes too much of a bother, consider implementing the "roll all POSTs into one" phase of your project sooner rather than later. That will likely avoid the necessity of having to add timers and file-locked handlers to your script(s).

Jim

[thinkcl]

Thanks JD - actually it's just doing a DB read - no writing. Someone suggested to me it is likely some sort of flood control with my host and that makes sense. I am going to contact them next.