Oversized request bodies let file uploads, API endpoints, and form handlers consume network, disk, and worker time before the application decides the payload is too large. Setting a request-body cap in Apache makes the web server reject that traffic early with HTTP 413 instead of passing large uploads deeper into the stack.

Apache HTTP Server uses the core LimitRequestBody directive to cap how many bytes it will accept for the body of a request in server config, virtual host, directory, file, or .htaccess context. Apply the directive in the narrowest scope that matches the upload endpoint so the limit affects only the requests that need it. A value of 0 means unlimited, while current Apache 2.4 releases default to 1073741824 bytes (1 GiB) and Apache 2.4.53 and earlier defaulted to unlimited.

The effective upload ceiling is always the smallest limit in the request path. Reverse proxies, application servers, and language runtimes such as PHP can still reject uploads with smaller limits, and WebDAV is a special case because LimitRequestBody does not control DAV request bodies. If request-body inflation is enabled through mod_deflate, Apache applies LimitRequestBody after decompression unless separate inflate limits are configured.

Steps to limit request body size in Apache:

  1. Pick the maximum request body size in bytes for the affected endpoint or directory.

    Common sizes: 1 MiB = 1048576, 10 MiB = 10485760, 50 MiB = 52428800, 100 MiB = 104857600. Leave headroom for multipart boundaries and extra form fields so a nominal 10 MiB file upload does not fail below the intended limit.

  2. Identify the active virtual host configuration file for the upload URL.
    $ sudo apache2ctl -S
    VirtualHost configuration:
    *:80                   uploads.example.net (/etc/apache2/sites-enabled/000-default.conf:1)
    ServerRoot: "/etc/apache2"
    Main DocumentRoot: "/var/www/html"
    Main ErrorLog: "/var/log/apache2/error.log"

    RHEL-family systems typically use /etc/httpd/conf.d/ and the httpd service name.

  3. Open the configuration file that serves the upload endpoint.
    $ sudoedit /etc/apache2/sites-available/000-default.conf

    On Debian and Ubuntu, edit the real file under /etc/apache2/sites-available/ instead of the symlink under /etc/apache2/sites-enabled/.

  4. Add LimitRequestBody in the smallest configuration context that matches the URL you want to protect.
    <VirtualHost *:80>
        ServerName uploads.example.net
    
        <Location "/upload">
            LimitRequestBody 10485760
        </Location>
    </VirtualHost>

    Use <Location> when the limit should follow a URL path such as /upload, or <Directory> when it should follow a filesystem path. Server configuration is preferred over .htaccess because it is easier to audit and does not depend on per-directory override settings.

  5. Validate the Apache configuration syntax before reloading the service.
    $ sudo apache2ctl configtest
    Syntax OK

    Some hosts also print the AH00558 server-name warning before Syntax OK; that warning does not block a successful syntax check.

  6. Reload the running Apache service to apply the new limit.
    $ sudo systemctl reload apache2

    Use sudo systemctl reload httpd on most RHEL-family systems.

  7. Create a test payload that is larger than the configured limit.
    $ dd if=/dev/zero of=/tmp/request-too-large.bin bs=1M count=11
    11+0 records in
    11+0 records out
    11534336 bytes (12 MB, 11 MiB) copied, 0.0034825 s, 3.3 GB/s
  8. Send the oversized payload to a URL covered by the limit and confirm that Apache returns HTTP 413.
    $ curl -s -o /dev/null -w "%{http_code}\n" -X POST --data-binary @/tmp/request-too-large.bin http://127.0.0.1/upload
    413

    If 127.0.0.1 does not hit the same virtual host locally, use the site hostname directly or add a Host header that matches the configured virtual host.

  9. Check the Apache access log for the rejected request.
    $ sudo tail -n 1 /var/log/apache2/access.log
    127.0.0.1 - - [09/Apr/2026:04:01:29 +0000] "POST /upload HTTP/1.1" 413 605 "-" "curl/7.88.1"

    RHEL-family systems commonly log to /var/log/httpd/access_log/ instead. A matching 413 entry confirms that the rejection happened at the Apache layer rather than deeper in the application stack.