Inconsistent HTTP 414 behavior for Apollo Server 4.x automatic persisted queries

Enforcement Strategy for URL Length

URL length limits for Automatic Persisted Queries (APQ) should be enforced at the outermost infrastructure layer (e.g., Load Balancer, Ingress Controller, or Reverse Proxy).

Because Apollo Server 4.x is transport-agnostic, it relies on the underlying Node.js or Express layer to handle URI limits. Relying on the application layer creates inconsistency because Node.js default header limits (often 8KB–16KB) vary by version and environment. Enforcing the limit at the gateway ensures that all requests are measured against a single, predictable standard before they reach the Node.js event loop, preventing inconsistent 414 (URI Too Long) or 431 (Request Header Fields Too Large) responses across different pods.

Distinguishing POST Fallbacks from Oversized GETs

To distinguish between a legitimate APQ fallback and a transport-level rejection, you must monitor the HTTP status code and the response body:

• Legitimate APQ Fallback: The server returns an HTTP 200 OK (or 400 Bad Request depending on configuration), but the response body contains a GraphQL error with the code PersistedQueryNotFound. This is the signal the Apollo Client uses to trigger the POST fallback.
• Oversized GET: The infrastructure or Node.js layer returns an HTTP 414 URI Too Long or HTTP 431 Request Header Fields Too Large. These are transport-level errors; the request never reaches the Apollo Server logic, and the client may not interpret these as a signal to fallback to POST, resulting in a hard failure.

Verification Steps

To verify your current threshold and behavior, use curl to send a GET request with a dummy query string exceeding 8KB:

curl -I "http://your-server/graphql?query=...[large_string]..."

If you receive a 414/431, the transport layer is rejecting the request. If you receive a 200 with a PersistedQueryNotFound error, the request reached Apollo Server.

Implementation Recommendation

1. Set a hard limit at the Gateway: Configure your NGINX or ALB to reject URIs above a specific threshold (e.g., 8KB).
2. Log 414s separately: Monitor your gateway logs for 414 errors to identify queries that are too large even for the hashed APQ format.
3. Audit Query Size: If 414s are frequent, investigate whether clients are sending excessively large variable sets within the GET request.

Missing Diagnostic Detail: Are you using a specific cloud load balancer or an ingress controller (e.g., NGINX, Traefik) in front of your Node.js instances? The specific configuration syntax for the limit depends on this layer.