Compare successful and failed uploads
Record file size, type, request duration and HTTP status for a passing and a failing case. A small upload does not prove that a large one will complete. Multiple files and form fields increase total request size.
If IIS rejects the request first, the application may never log it. If the application receives it and fails later, investigate temporary storage, destination space, permissions and processing. Treat a timeout and a size rejection as separate hypotheses.
Normalize limits before comparing them
| Layer | What to inspect |
|---|---|
| IIS request filtering | Request size settings such as maxAllowedContentLength |
| PHP | The relationship between upload_max_filesize and post_max_size |
| Proxy and application | Body size, duration and application-specific file rules |
| Storage | Temporary space, destination quota and write permissions |
Define a size and duration budget
Account for the permitted file size, file count per request and form overhead. For example, if a product accepts a 20 MiB file, setting the total request limit to exactly that size can reject a valid boundary case. This is an illustrative product requirement, not a universal server setting.
Slow transfer, scanning and transformation have different time budgets. Long processing may require a tracked background job after upload acceptance. Raising a timeout does not prove that processing finishes successfully.
Test boundaries and recovery behavior
- Record current values and their scope, then apply the change on a test site.
- Try files below, at and above the intended boundary and verify the expected acceptance or rejection.
- Test multiple files, slow transfers and interrupted connections; check temporary-file cleanup.
- Verify that other sites retain their limits and storage consumption remains controlled.
Separate acceptance from safe handling
Limit allowed types to the business requirement. Do not map a user-provided filename directly into an executable web location. Private uploads need deliberate storage and authorization for download.
Return a useful user-facing error without exposing filesystem paths or configuration. Track disk pressure, rejected requests and failed processing jobs as separate outcomes so a completed transfer cannot conceal a later failure.
On shared hosting, evaluate per-customer storage budgets too. One user’s otherwise valid uploads should not consume the disk space required by every site.
Frequently asked questions
Why does an upload fail after increasing the PHP limit?
IIS, a proxy or the application may reject it earlier. Use status details and logs to identify the last layer reached.
Should post_max_size equal the file limit?
Total POST data includes form fields and multipart overhead as well as the file. Plan file and total request budgets together.
Should all upload limits be unlimited?
Set a boundary justified by the product. Unlimited acceptance makes storage, memory and processing load harder to control.
Does upload completion prove conversion is complete?
No. Transfer, storage and background processing can be separate stages. Report the stage that has actually completed.