Firefox 115+ POST retry behavior with network.http.retry.enable_post and Retry-After header

Direct answer

With network.http.retry.enable_post enabled in Firefox 115+, the only confirmed automatic retry behavior in model knowledge is a retry of POST requests that receive a 503 response with a Retry-After header. The browser checks that the request body is unchanged between attempts and delays the retry to honor the server-supplied Retry-After value.

No confirmed public specification or stable documentation shows additional trigger conditions, method coverage beyond POST, or an independent retry count / exponential backoff for this experimental preference.

Confirmed facts

• network.http.retry.enable_post exists as a hidden experimental preference from Firefox 115 onward. It is not exposed in the UI.
• The described intent is to allow automatic retry of POST requests that receive 503 with Retry-After.
• The retry logic is documented as verifying the request body is unchanged between attempts and honoring the delay specified by Retry-After.
• The feature remains experimental and undocumented, so behavior is version-sensitive and can change without notice.

Likely explanation vs unverified

Likely explanation: the feature was designed POST-specific to mitigate temporary overload on non-idempotent submissions. No verified evidence in available knowledge shows extension to PATCH, PUT, or other non-idempotent methods.

Unverified: additional status codes triggering retry, support for PATCH or other methods, a maximum retry limit, or an exponential backoff implemented independently of the server-supplied Retry-After value. Absence of documentation means these are not confirmed.

Risk note: automatic retry of POST can cause duplicate side-effects if the endpoint is not designed for safe repetition, even with body unchanged checks.

Scoped verification you can run

1. Open about:config in Firefox 115+ and confirm network.http.retry.enable_post exists and is set to true.
2. Use a controlled test server that returns 503 with Retry-After for a POST request. Observe in Network tools whether a single automatic retry occurs and whether the delay matches the header.
3. Repeat the test with PATCH and with 503 without Retry-After, and with other 5xx codes, to check for any retry. Document the Firefox build number used.
4. Inspect Firefox release notes and source change logs for network.http.retry entries to identify any documented status codes, methods, and limits for your build.

One diagnostic detail that changes the recommendation: the exact Firefox build / ESR channel you are testing on. Experimental network retry behavior is version-sensitive and may differ between 115, 128 ESR, and later releases.