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

Automatic persisted queries in Apollo Client send a SHA-256 hash via GET and fall back to POST when the server does not recognize the hash. Because the HTTP specification does not define a maximum URL length, Apollo Server 4.x does not proactively reject long GET request URIs. Instead, an error surfaces only when the underlying Node.js or Express layer throws, which can produce inconsistent behavior across deployments.

This leaves an unresolved design decision about which layer should enforce a safe URL length: the client, the server, or an intermediate gateway. The automatic fallback to POST can also obscure configuration problems by silently retrying with the full query body, making it harder to detect when queries are unnecessarily large. Additionally, future changes to the persisted query link implementation may alter the fallback threshold, potentially breaking clients that depend on the current behavior.

Where should URL length limits for automatic persisted queries be enforced, and what observable signal can distinguish a legitimate POST fallback from an oversized GET that should have been rejected or logged?