HTML5 form submission lacks built-in deduplication for non-idempotent POST resubmission

Question

Limits of native duplicate preventionThe HTML Living Standard defines form submission with method="POST" as non-idempotent but does not specify any browser-level mechanism to prevent duplicate server-side processing when a user manually resubmits—whether by refreshing a POST result page, navigating back/forward, or restoring a page from bfcache. The spec provides no idempotency-key attribute, submission token, or automatic deduplication flag, and browsers do not automatically retry failed POST requests on network error or 5xx responses.Current workarounds are application-levelDevelopers must implement patterns such as Post-Redirect-Get (PRG), disabling the submit button via JavaScript after first click, or generating and validating server-side idempotency keys. The autocomplete and form-state restoration features preserve user-entered data across navigation but do not track whether a submission has already been sent. Service Workers can intercept fetch events to add custom retry logic with idempotency keys, yet this remains an opt-in progressive enhancement rather than default HTML5 behavior.Open questionsAre there any proposed spec additions (e.g., a dedupe attribute or standard idempotency-key header) that would give browsers a native signal to suppress duplicate POST submissions?Does the current bfcache restoration algorithm in major engines ever re-dispatch a submit event automatically, or is a user gesture always required?What is the recommended verification approach to confirm that a given browser version will not silently re-POST on back/forward navigation without a confirmation prompt?

Tasadduq Burney · Answer

Answer
HTML5 does not include any native mechanism to prevent duplicate POST submissions; each form submission with method="POST" is treated as an independent request unless the application adds its own deduplication logic.
Confirmed facts from the specification and browser behavior

The HTML Living Standard defines POST as non‑idempotent but provides no idempotency-key attribute, dedupe flag, or automatic retry on network errors.
Browsers do not automatically resend a POST when a page is restored from the back/forward cache (bfcache); a user gesture is required to trigger a new submission.
Proposals for a standard dedupe attribute or idempotency‑key header have been discussed in WHATWG but are not part of the current spec.

Verification steps for a specific browser version

Create a test endpoint that increments a counter or logs a timestamp for every POST it receives.
Load a simple HTML form that posts to that endpoint, submit the form, and record the log count.
Navigate away from the page (e.g., follow a link) then use the browser’s back button or history.back() to return to the form page.
Check the server log again; if the count has not increased, the browser did not silently re‑POST.
Repeat the test in incognito/private mode and with cache disabled to rule out bfcache variations.

If you need a recommendation that works across all browsers, implement the Post‑Redirect‑Get (PRG) pattern or validate a server‑side idempotency key; client‑only tricks such as disabling the submit button can fail when scripts are blocked or the page is restored from bfcache.

HTML5 form submission lacks built-in deduplication for non-idempotent POST resubmission

Limits of native duplicate prevention

Current workarounds are application-level

Open questions

1 answer

Answer

Confirmed facts from the specification and browser behavior

Verification steps for a specific browser version

Your perspective belongs here.

0 question comments