HTTP 413 Request Entity Too Large: Causes, Server Limits & Workarounds

In production web systems, an HTTP 413 error appears the moment an incoming payload crosses a hard buffer limit: Nginx defaults client_max_body_size to 1 MB, Cloudflare Free and Pro accounts cap request bodies at 100 MB, and AWS Application Load Balancers truncate requests directed to AWS Lambda targets at 1 MB. When engineering teams or autonomous agent pipelines push large media files, database backups, or document collections across HTTP connections, the request fails at the network boundary before application code ever parses a single byte.

HTTP 413 Request Entity Too Large (renamed Payload Too Large in HTTP/1.1 RFC 7231 / RFC 9110) indicates that the server or intermediary proxy refuses to process a request because the request payload exceeds the configured server body limit. While older specifications designated the status code as Request Entity Too Large, modern HTTP standards refer to it as Payload Too Large to reflect that HTTP messages carry representations and payloads rather than raw entities. Servers receiving an oversized payload may close the TCP connection immediately to prevent the client from continuing to transmit unwanted bytes across the wire. When the refusal condition is temporary, servers can optionally return a Retry-After header indicating when the client may attempt the transmission again.

In everyday web development and distributed architecture, HTTP 413 errors cluster around three distinct operations:

1. Direct File and Media Uploads: Users or background workers attempt to transmit high-resolution video assets, uncompressed audio files, disk images, or oversized PDF documents through a standard web form or API endpoint without client-side chunking.
2. Bulk Data and Serialized API Payloads: Microservices exchange large batches of serialized records, such as massive JSON arrays or XML documents containing embedded Base64 strings. Because Base64 encoding inflates binary payload volume by one-third, a file approaching standard boundaries expands during conversion into ASCII text, tripping proxy limits unexpectedly.
3. AI Agent Ingestion Pipelines: Autonomous agents and Retrieval-Augmented Generation (RAG) indexers attempt to post whole documentation repositories, legal matter binders, or scanned archive sets directly into language model endpoints or context extraction services. In AI agent workflows, similar ceilings appear at the application boundary: as documented by the Anthropic Help Center, Claude chat sessions accept up to 20 files at up to 500 MB per file, while Claude Projects accept files up to 30 MB each with no fixed file-count cap, bounded only by the model's context window. Crossing these thresholds produces immediate ingestion failures.

The Mechanics of HTTP Payload Rejection

When a client initiates an HTTP request containing a body, it typically sends a Content-Length header indicating the size of the payload in bytes. Web servers and reverse proxies evaluate this header during the initial request-line and header parsing phase. If the value in Content-Length exceeds the configured buffer limit, the receiving software terminates processing immediately without reading the incoming message body.

In HTTP/1.1 connections, a server responding with an HTTP 413 status code frequently appends a Connection: close header and terminates the underlying TCP socket. This abrupt closure prevents the client from wasting network bandwidth uploading megabytes or gigabytes of unprocessable data. In HTTP/2 and HTTP/3 multiplexed connections, where multiple logical streams share a single transport connection, the server resets the offending stream using an RST_STREAM frame while maintaining other active requests on the same connection.

When a client transmits data using chunked transfer encoding (Transfer-Encoding: chunked), the total payload size is omitted from the initial headers. In this scenario, web servers buffer incoming data chunks until either the stream terminates or accumulated bytes exceed the buffer ceiling. Once the ceiling is reached, the server halts buffering and returns an HTTP 413 status code.

Default Thresholds Across Web Servers and Reverse Proxies

Web servers and reverse proxies enforce strict default body limits to shield internal resources from denial-of-service conditions, memory exhaustion, and slow-rate transmission attacks. Without an enforced ceiling, a small number of concurrent clients streaming multi-gigabyte payloads could consume all available thread pool memory or fill local temporary storage disks.

The following comparison table details default payload limits, maximum configurable thresholds, and primary configuration directives across leading web servers, load balancers, and reverse proxies:

Understanding where your infrastructure sits relative to these boundaries helps diagnose failures quickly. In multi-tiered architectures, the lowest configured limit along the network path dictates the effective ceiling for the entire application.

• Salesforce Agentforce Limits: Tokens, Context Windows, and Grounding File CapsAgentforce limits establish operational boundaries for autonomous AI across Salesforce, including a 1.5 million hourly...
• ChatGPT Deep Research Limits: Plan Quotas, Reset Rules, and Workspace SolutionsChatGPT Deep Research limits restrict autonomous research tasks through plan-based quotas, rolling 30-day reset cycles,...
• Custom GPT Token Limit: Instruction Limits, Context Windows, and RetrievalThe Custom GPT token limit refers to the 8,000-character constraint on configuration instructions and the dynamic...
• Ollama Max Tokens: Setting Generation Limits and Context BudgetsIn Ollama, setting generation limits requires configuring the num_predict parameter, which sets the maximum number of...
• Amazon SNS Message Size Limit: 256 KB Payload Caps, Protocols, and Large PayloadsThe Amazon SNS message size limit is a default quota of 256 KB (262,144 bytes) across message bodies and attributes....
• DynamoDB Item Size Limit: The 400 KB Cap, ValidationException, and Storage PatternsThe DynamoDB item size limit is a strict maximum of 400 KB per item, calculated by summing the byte lengths of all...

More on this subject: AI Agents: General Guides (172 guides)

Resolving an HTTP 413 error begins at the web server layer. If your application sits directly behind Nginx, Apache, or Microsoft IIS without an intermediate content delivery network, updating a single configuration directive restores normal file ingestion. However, configuring the web server is only the first step: backend runtimes such as PHP-FPM, Node.js Express, and Python WSGI servers enforce secondary request body limits that must align with the web server.

Configuring Web Server Request Limits

In Nginx, the client_max_body_size directive governs the maximum allowable size of the client request body. If the Content-Length header of a request exceeds this configured value, Nginx stops processing the request and returns an HTTP 413 status code.

You can declare client_max_body_size at three distinct scope levels within your nginx.conf file:

• Global Context (http): Applies the upload limit across all virtual hosts and server blocks managed by the Nginx instance.
• Virtual Host Context (server): Sets the limit for a specific domain name or port.
• Route Context (location): Restricts the larger limit strictly to dedicated file ingestion endpoints, leaving public browsing routes hardened against oversized payloads.

The following configuration snippet sets a global 50 MB limit while isolating an ingestion route to accept up to 250 MB:

http {
    client_max_body_size 50M;
    server {
        listen 80;
        server_name api.example.com;
        location / {
            proxy_pass http://backend_upstream;
        }
        location /api/v1/uploads/ {
            client_max_body_size 250M;
            proxy_pass http://backend_upstream;
            proxy_read_timeout 300s;
            proxy_connect_timeout 75s;
        }
    }
}

After editing nginx.conf, test your configuration syntax by running nginx -t. If the syntax check passes, reload the service using nginx -s reload to apply the changes without interrupting active network connections.

In Apache HTTP Server, the governing directive is LimitRequestBody. This directive specifies the number of bytes allowed in an HTTP request body, accepting values from 0 (meaning unlimited) up to 2147483647 bytes (approximately 2 GB) in older releases, or unlimited in Apache 2.4.54 and later. You can configure LimitRequestBody in your primary server configuration (httpd.conf or apache2.conf), inside a <VirtualHost> block, or within a directory-level .htaccess file:

<VirtualHost *:80>
    ServerName api.example.com
    DocumentRoot /var/www/html
    LimitRequestBody 104857600
    <Directory "/var/www/html/uploads">
        LimitRequestBody 262144000
    </Directory>
</VirtualHost>

Test your Apache configuration using apachectl configtest and apply the update with systemctl reload apache2 or systemctl reload httpd.

For Microsoft Internet Information Services (IIS), request filtering and runtime processing both enforce body limits. You must update both maxAllowedContentLength and maxRequestLength in your application's web.config file:

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="104857600" />
      </requestFiltering>
    </security>
  </system.webServer>
  <system.web>
    <httpRuntime maxRequestLength="102400" executionTimeout="300" />
  </system.web>
</configuration>

Note that maxAllowedContentLength is specified in bytes, whereas maxRequestLength in ASP.NET is specified in kilobytes. Mismatched units between these two settings are a frequent source of lingering 413 errors in Windows environments.

Synchronizing Backend Application Runtimes

Raising your web server limits resolves the initial gateway rejection, but if your backend application framework enforces lower memory or file ingestion thresholds, the request will fail further down the stack.

In PHP applications managed by PHP-FPM, check five core directives in php.ini:

• upload_max_filesize: The maximum size of an individual uploaded file (for example, 100M).
• post_max_size: The maximum size of the entire POST body, including form fields and file data. This value must be set higher than upload_max_filesize (for example, 105M).
• memory_limit: The maximum memory a single PHP worker script may allocate. This must exceed post_max_size (for example, 256M).
• max_execution_time: The maximum time in seconds a script can run before termination (for example, 300).
• max_input_time: The maximum time in seconds a script may spend parsing input data (for example, 300).

After adjusting these values, restart your PHP-FPM service (for example, systemctl restart php8.2-fpm).

In Node.js applications using Express, the built-in body parsing middleware defaults to strict limits (100 KB for JSON bodies). If your API accepts serialized JSON payloads containing Base64 data, configure the middleware limits explicitly:

import express from 'express';

const app = express();

app.use(express.json({ limit: '50mb' }));
app.use(express.urlencoded({ limit: '50mb', extended: true }));

For multipart form-data handling in Node.js, libraries such as multer or formidable require explicit configuration of file size limits, as they reject files exceeding their internal thresholds regardless of Express settings.

In Python Django applications, verify DATA_UPLOAD_MAX_MEMORY_SIZE and FILE_UPLOAD_MAX_MEMORY_SIZE in settings.py. Both default to 2.5 MB (2,621,440 bytes). Increase them to accommodate expected file volumes.

Solve 413 Request Entity Too Large Errors with Intelligent Workspaces

Connect Claude, Cursor, and autonomous agents to Fast.io workspaces over MCP. Store multi-gigabyte corpora, index documents for hybrid search, and bypass 413 request entity too large errors on large file transfers. Monthly plans start with a 14-day free trial.

Start 14-Day Trial

When an application runs behind a content delivery network or a managed cloud load balancer, web server configurations represent only the final hop in a multi-stage request pipeline. If an intermediate proxy enforces a stricter buffer ceiling than your origin server, client requests fail before ever reaching your infrastructure.

Cloudflare Edge Ceilings and Zone Plans

When a domain routes traffic through Cloudflare with proxying enabled (the orange-cloud DNS state), Cloudflare edge servers terminate client connections and inspect incoming HTTP headers. Cloudflare enforces fixed maximum client request body sizes based on the domain's subscription tier:

• Free and Pro Plans: Capped at 100 MB per request.
• Business Plan: Capped at 200 MB per request.
• Enterprise Plan: Defaults to 100 MB, with self-serve configuration up to 5 GB via the Cloudflare dashboard or API.

If an incoming upload carries a Content-Length header exceeding the zone plan ceiling, Cloudflare immediately returns an edge HTTP 413 error. The request never reaches your origin server, and origin web server access logs will record no entry for the attempt.

Engineering teams facing Cloudflare proxy limits have three potential solutions:

1. Upgrade Plan Tier: Moving from Pro to Business doubles the upload limit to 200 MB, while Enterprise provides up to 5 GB per request.
2. Direct Subdomain Bypass: Create a dedicated DNS record for uploads (such as direct-upload.example.com) and disable Cloudflare proxying (grey-cloud state). This routes traffic directly to your origin web server, allowing custom Nginx or Apache limits to take effect. Note that bypassing Cloudflare removes edge caching, DDoS protection, and Web Application Firewall rules for that specific subdomain.
3. Direct-to-Storage Architecture: Generate presigned upload URLs that direct clients to upload files directly into cloud object storage, bypassing Cloudflare entirely.

Cloud Load Balancers and Gateway Quotas

Managed load balancers and API gateways across cloud providers enforce hard ceilings that cannot be adjusted via standard configuration directives:

• AWS Application Load Balancer (ALB): When an ALB routes requests to standard targets like Amazon EC2 instances or Amazon ECS containers, it accommodates large request bodies. However, when an ALB targets AWS Lambda functions, AWS enforces a hard, non-configurable 1 MB payload limit on both request and response bodies. Requests over 1 MB receive an automatic HTTP 413 Payload Too Large error generated directly by the ALB.
• Amazon API Gateway: REST APIs and HTTP APIs in Amazon API Gateway enforce a fixed maximum payload size quota of 10 MB. Payloads exceeding this threshold are rejected at the gateway boundary.
• Google Cloud Load Balancing: Google Cloud HTTP(S) Load Balancers support streaming uploads, but individual backend services and serverless network endpoint groups (NEGs) enforce integration ceilings.

In distributed cloud topologies, the lowest limit along the path acts as the effective system ceiling. Increasing origin server capacity does not overcome edge proxy or gateway restrictions.

The rapid adoption of autonomous AI agents, coding assistants (such as Claude Code, Cursor, and Cline), and Retrieval-Augmented Generation (RAG) pipelines has introduced a new vector for HTTP 413 errors. In these workflows, agents often need to ingest extensive technical documentation, multi-gigabyte codebases, and dense document archives to perform analysis, planning, and task execution.

Context Windows Compared to HTTP Request Bodies

A common implementation pattern among early AI agent projects involves bundling raw source files, PDFs, or database extracts directly into API request payloads. When an agent attempts to transmit a large batch of legal filings or codebase dumps in a single JSON payload to an LLM endpoint or embedding service, it frequently triggers an HTTP 413 error at an intermediate gateway or ingress proxy.

Even when the underlying HTTP endpoint permits large payloads, stuffing raw document corpora directly into model prompts creates severe operational problems:

• Context Window Saturation: While chat interfaces like Claude allow up to 20 files at up to 500 MB per file, Claude Projects enforce a 30 MB per-file limit with no fixed file-count cap, requiring all project files to fit within the model's context window. Attempting to attach large document sets directly exhausts available context tokens.
• Inference Latency and Cost: Sending hundreds of pages of unindexed text on every prompt iteration increases input token processing costs and inflates round-trip response latency.
• Memory Pressure on Agent Runtimes: Serializing large document sets into JSON strings in agent memory causes heap spikes and process termination in constrained worker environments.

Decoupling Storage from Inference via MCP

To solve these constraints, modern agent architectures decouple persistent document storage from the model inference loop. Instead of pushing whole files through HTTP request bodies, teams store their document libraries in a persistent, shared workspace.

In this architecture, document collections reside in org-owned Fast.io workspaces. Teams can upload files directly or bring existing assets from Google Drive, Dropbox, Box, or OneDrive via Cloud Sync.

Once documents are stored in the workspace, enabling Intelligence Mode indexes the content across full-text, semantic vectors, and metadata values. Rather than sending oversized payloads across HTTP connections, AI assistants and autonomous agents connect to the workspace through the remote Model Context Protocol (MCP) server at https://mcp.fast.io/mcp/tools over Streamable HTTP.

When an agent needs context to complete a task, it uses the MCP storage search action to retrieve only the precise passages or data points relevant to the user query. This approach leaves vendor upload limits intact while giving agents access to multi-gigabyte document corpora without triggering 413 payload errors or exhausting model context windows.

For teams building production web applications, data ingestion pipelines, and agentic platforms, relying on inflated web server buffer directives is rarely sufficient. A single large transfer can saturate server memory or tie up worker threads. Modern engineering practices resolve payload limits through three architectural patterns.

Direct-to-Storage Presigned Uploads

Direct-to-storage architecture removes file uploads from application servers entirely. Instead of routing multi-megabyte payloads through Nginx, Express, or Django, the client communicates directly with object storage:

1. Token Request: The client sends a lightweight JSON request containing metadata (filename, content type, file size) to the application API.
2. Presigned URL Generation: The API validates client permissions and generates a short-lived presigned upload URL directly to cloud object storage (such as Amazon S3, Google Cloud Storage, or workspace storage).
3. Direct Upload: The client uploads the binary payload directly to the storage service using an HTTP PUT request. Because the upload bypasses the application reverse proxy and web server, proxy buffer limits no longer apply.
4. Completion Notification: Once the upload finishes, the storage service or client notifies the application backend via an asynchronous event or activity stream.

Resumable Chunked Multipart Transfers

When files must pass through HTTP endpoints or when dealing with multi-gigabyte media assets, chunked multipart uploads divide the payload into small segments (typically 5 MB to 10 MB each).

Each chunk is transmitted in an independent HTTP POST or PUT request with its own Content-Length header, well below the 100 MB Cloudflare ceiling and standard Nginx configurations. Resumable upload protocols (such as Tus or S3 multipart APIs) track upload state on the server. If a network interruption occurs, the client resumes transmission from the last successful chunk rather than re-uploading the entire file from scratch. Fast.io workspaces incorporate chunked upload mechanics, supporting large file ingestion up to plan limits (25 GB on Starter, 50 GB on Business, and 100 GB on Enterprise).

The following evaluation table compares primary architectures for handling large data ingestion:

When debugging 413 errors in production, inspect the Server response header to identify which layer rejected the transmission (cloudflare, nginx, or awselb/2.0). Examine the outgoing Content-Length header against the identified ceiling, and consider moving to chunked transfers or external workspace indexing when payload volumes exceed 50 MB.