Production Validation API returns HTTP 413 (Request Entity Too Large) for a notice accepted by the Preview environment #1368
|
We are submitting an eForms notice to the Validation API and observe inconsistent behaviour between the production and preview environments for the exact same request.
Request details (identical in both environments):
Observed behaviour:
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx</center>
</body>The 413 is returned by nginx (the API gateway), before the request reaches the validation service. Conclusion / Question It appears that the production Validation API gateway is configured with a lower request body size limit (client_max_body_size) than the preview environment, which causes valid notices to be rejected on production while the same payload is accepted on preview. Could you please:
Impact: We are currently unable to validate (and therefore submit) larger notices on production, even though they validate successfully on the preview environment. |
Replies: 3 comments
|
Dear @sajolevente-tigra, Thank you for bringing this issue to our attention. For reference, we’ve tested the production endpoint (api.ted.europa.eu/.../validate) with a 6.64 MB Base64-encoded payload (larger than your reported ~3.91 MB case) and confirmed it completed successfully (HTTP 200). To help us diagnose this further, would you be able to: Thank you. |
|
Hi Stefan, Thank you for testing on your side. To answer your questions and share what we found:
New finding from our logs:
Could you please check your production gateway / load-balancer logs around 2026-05-23, 15:00-15:50 UTC to confirm whether there was any maintenance, deployment, partial outage, or config change affecting one of the backend nodes during that window? Thank you, |
|
Dear Levente, Thank you for your thorough investigation and for raising this issue. The detailed logs and timeline you provided helped us identify the cause. Best regards, |
Hi Stefan,
Thank you for testing on your side. To answer your questions and share what we found:
Identical conditions?
Yes. The only difference between the two calls was the endpoint host (
api.preview.ted.europa.euvs.api.ted.europa.eu). Same payload, sameContent-Type: application/json, same body (Base64-encodednotice,language).Proxy/firewall on our end?
Our outbound requests pass through our own reverse proxy, but that is not the source of the 413: the error page returned was an nginx 413 page (we run Apache, not nginx)
New finding from our logs:
After reviewing our request history, we found that all failures were confined to a single ~40-minute window on 2026-05-23. Every req…