Skip to content

Navigation Menu

Sign in
Sign up

Production Validation API returns HTTP 413 (Request Entity Too Large) for a notice accepted by the Preview environment #1368

Discussion options

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.

Environment Endpoint Result
Production POST https://api.ted.europa.eu/.../validate ❌ Fails (HTTP 413)
Preview POST https://api.preview.ted.europa.eu/.../validate ✅ Succeeds (HTTP 200)

Request details (identical in both environments):

  • Method: POST
  • Content-Type: application/json
  • Body: JSON object containing the notice XML Base64-encoded in the notice field, plus language and validationMode: "dynamic"
  • Notice XML raw size: 3,076,459 bytes (~2.93 MB)
  • Resulting Base64-encoded request body: ~4,101,948 bytes (~3.91 MB)

Observed behaviour:

  • On the preview environment the request is accepted and validated normally (HTTP 200).
  • On the production environment the same request is rejected by the nginx gateway with HTTP 413:
<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:

  1. Confirm the current request body size limit on the production Validation API gateway.
  2. Align the production limit with the preview environment (or document the maximum supported notice size for the Validation API).

Impact: We are currently unable to validate (and therefore submit) larger notices on production, even though they validate successfully on the preview environment.

You must be logged in to vote

Hi Stefan,

Thank you for testing on your side. To answer your questions and share what we found:

  1. Identical conditions?
    Yes. The only difference between the two calls was the endpoint host (api.preview.ted.europa.eu vs. api.ted.europa.eu). Same payload, same Content-Type: application/json, same body (Base64-encoded notice, language).

  2. 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...

Replies: 3 comments

Comment options

Dear @sajolevente-tigra,

Thank you for bringing this issue to our attention.
To better understand the discrepancy, could you clarify the following:
• Are you using identical conditions for both environments, with the only difference being the endpoint URL (preview vs. production)?
• Are your requests being routed through a proxy or firewall on your end?

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:
Retry your original request (the ~3.91 MB payload) using Postman or curl and share:
• The full response headers (if the error persists).
• The exact timestamp of the test (to cross-reference with our logs).

Thank you.
Best regards,
Stefan

You must be logged in to vote
0 replies
Comment options

Hi Stefan,

Thank you for testing on your side. To answer your questions and share what we found:

  1. Identical conditions?
    Yes. The only difference between the two calls was the endpoint host (api.preview.ted.europa.eu vs. api.ted.europa.eu). Same payload, same Content-Type: application/json, same body (Base64-encoded notice, language).

  2. 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 request to the production Validation API on every other day (both before and after), with payloads of similar and larger size, completed successfully. We also could not reproduce the issue afterwards: a fresh ~5 MB Base64 test succeeded on both production and preview (matching your own 6.64 MB success test).

Start time (UTC) Result
2026年05月21日 09:11:34 200 (OK)
2026年05月23日 15:03:43 413 (failed)
2026年05月23日 15:07:57 413 (failed)
2026年05月23日 15:11:56 413 (failed)
2026年05月23日 15:21:13 413 (failed)
2026年05月23日 15:23:28 413 (failed)
2026年05月23日 15:45:00 413 (failed)
2026年05月24日 09:21:01 200 (OK)

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,
Levente

You must be logged in to vote
0 replies
Answer selected by YvesJo
Comment options

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.
We can confirm that the HTTP 413 responses observed on 23/05 between approximately 15:00 and 15:50 UTC were caused by an unintended configuration issue affecting the production TED API gateway. This resulted in a temporary request-size limitation being applied incorrectly.
This impact was not expected, which is why no prior communication was issued for the TED API. The issue has since been corrected, and the configuration has been reviewed to prevent this from recurring.
We apologise for the inconvenience caused and appreciate your patience and diligence in reporting this.

Best regards,
Stefan

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet

AltStyle によって変換されたページ (->オリジナル) /