Bug 319396 – REGRESSION (Safari 26.5.2): Silently submits multipart/form-data POST with Content-Length: 0 when a file input's data is no longer readable (e.g., form resubmitted from a restored/suspended tab)

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Forms

[Christian DeLoach]

Beginning with Safari 26.5.2 (released June 29, 2026), submitting an HTML form containing a populated <input type="file"> can produce an HTTP POST with Content-Type: multipart/form-data; boundary=… but Content-Length: 0 and no request body whatsoever — no boundary, no text fields, no file. The browser shows no error to the user; the site receives an unparseable request. The previous release, Safari 26.5, does not exhibit this behavior, nor does any earlier Safari version. Safari 26.6 (pre-release) exhibits the same behavior.

The trigger appears to be the file input's underlying file data becoming unreadable between selection and submission — most commonly when the user returns to a suspended or restored tab in which the form (including the file selection) was preserved, and submits. Instead of blocking submission or clearing the stale file input, Safari 26.5.2 sends the bodyless POST.

Steps to reproduce

Open a page with a standard <form method="post" enctype="multipart/form-data"> containing text fields and an <input type="file"> (no JavaScript involvement required; plain form submission).
Fill the form and attach a file (a multi-MB JPEG photo is typical in our data).
Leave the tab idle for several minutes, background Safari (on iOS, switch apps or lock the device), or allow the tab to be suspended and later restored. The form still appears fully populated, including the file input.
Return to the tab and submit the form.
Expected: The form submits with the full multipart body; or, if the file data is no longer accessible, Safari surfaces an error / clears the file input rather than submitting.

Actual: Safari sends POST with Content-Type: multipart/form-data; boundary=----WebKitFormBoundary… and Content-Length: 0, transmitting zero body bytes (confirmed server-side via Apache %I byte counts: 417–573 bytes received per request — TLS/header overhead only). No error is shown in the browser. Retrying submission fails identically until the user re-selects the file.

Version/configuration information

Safari 26.5.2 on macOS (UA: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5.2 Safari/605.1.15)
Safari 26.5.2 on iOS 18.7 (iPhone OS 18_7 … Version/26.5.2 Mobile/15E148)
Also observed from WebKit-based third-party iOS browsers (CriOS, EdgiOS) on the same OS builds
Safari 26.6 (pre-release) — same failure signature
Not reproducible on Safari 26.5 or any earlier build (see data below)
Supporting data (from a production web server, universityhealthplans.com — student health-insurance waiver forms with a required document upload)

Over July 3–12, 2026, across 172,689 form POSTs with server-side logging of bytes received per request:

Safari 26.5.2: 125 bodyless-POST failures in 2,784 POSTs (4.49%)
Safari 26.6: 23 failures in 516 POSTs (4.46%)
Safari 26.5: 0 failures in 39,779 POSTs
All other Safari builds (17.x, 18.x, 26.0–26.4): zero or near-zero
Chromium-based desktop/Android browsers (~52% of traffic): zero failures
Daily failure counts scale with 26.5.2's adoption share (1.4% → 18.2% of our Safari traffic over the period), beginning within days of the June 29 release
Every captured failure received 417–573 bytes total (request headers only); successful submissions from the same form receive 3–6 MB
33% of failures arrive as the client IP's first request of the day — i.e., a form submission with no preceding page load, consistent with resubmission from a restored tab — and another 35% follow 5+ minutes of client inactivity
Failures repeat deterministically on retry until the file is re-selected
Sample server log line (structured logging we added):
WAIVER_UPLOAD_TRUNCATED | protocol=HTTP/2.0 | request_method=POST | content_type=multipart/form-data; boundary=----WebKitFormBoundaryyAZtjJ1yAFVj89BJ | content_length=0 | remote_addr=… | user_agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.5.2 Safari/605.1.15

Impact

Users submitting time-sensitive health-insurance waiver applications lose their entire submission with no browser-side indication of failure. On this one site, 175+ failed submissions in 10 days, most never successfully retried. Any site accepting file uploads via multipart forms is presumably affected as 26.5.2 adoption grows.

Possibly related

Safari 26.5.2 was a security-focused release; the behavior is consistent with file-access hardening causing reads of retained file references to fail closed at submit time. Possibly related to the "Local File Restrictions" behavior others have reported breaking uploads in Safari 26 (e.g., github.com/orgs/community/discussions/191840). The failure mode parallels a historical Gecko bug (Mozilla #1434553 — resubmitted multipart POSTs from stored session state losing body length), suggesting the same resubmission path.

[Radar WebKit Bug Importer]

<rdar://problem/182347736>

[Per Arne Vollan]

I am not able to reproduce on macOS when choosing a file from the Downloads folder, leaving Safari in the background for a few minutes, and submitting. Do you have detailed reproduction steps?

[Per Arne Vollan]

If you are able to reproduce locally, can you also send a Feedback report. That will provide us with more information.

[Christian DeLoach]

After a couple weeks of troubleshooting, it has been determined that a majority of the errors are coming from a change in Safari where tabs left open are reposted, likely during the recreation of the tab thumbnail previews. We've noticed a 4X increase in duplicate submissions errors caused by Safari resubmitting the form. When Safari resubmits the form, and the file no longer exists, Safari now sends a header but no body. We updated our form submission program with a custom handler to address the "Malformed multipart POST: data truncated" errors coming from this update. Some website visitors have reported multiple failed attempts to upload their file. I suspect it may be caused by a cloud-hosted file not fully downloaded when the form is submitted.

I've been able to reproduce the error on my end by leaving a submitted form's confirmation page open in a tab, then, in Safari, clicking "All Tabs" a day after submitting the form, and I saw our error handler page. Why is Safari now re-POSTing form submissions when re-generating the tab thumbnail previews?

I re-ran a report this morning based on web logs for the past 14 days. Here are the numbers:

Safari 26.5.2
46,188 form POSTs
1,578 failures
3.42%

Safari 26.6
965 form POSTs
29 failures
3.01%

Safari 26.x / 27 (other recent)
36,909 form POSTs
9 failures
0.02%

Safari ≤18 (older)
21,970 form POSTs
0 failures
0.00%

iOS non-Safari, WebKit (Chrome/Edge/Firefox on iOS)
14,002 form POSTs
282	failures
2.01%

Non-Safari, non-WebKit (desktop Chrome/Edge/FF, Android, bots)
174,985 form POSTs
8 failures
<0.00001%

Total:
295,019 form POSTs
1,906 failures
0.65%

Safari 27.0 may be the fix. 381 POSTs, zero failures (it's in the "26.x/27 other" bucket, whose 9 failures are all trace 26.4/26.5).

[Alexey Proskuryakov]

*** Bug 320904 has been marked as a duplicate of this bug. ***

my report, bug https://bugs.webkit.org/show_bug.cgi?id=320904, was marked as a duplicate of this one. We're hitting what looks like the exact same signature described here (multipart/form-data POST sent with Content-Length: 0 and an empty body on Safari 26.5.2, no error shown to the user), but without any of the tab suspension/backgrounding/restoration steps listed above.

My repro is a straight, uninterrupted flow in a single foreground tab:
  1. Load a page with a form (enctype="multipart/form-data") containing a text field and a file input.
  2. Select a file from the native Files/Photos picker.
  3. The page immediately builds a FormData from the form and POSTs it via XMLHttpRequest (jQuery $.ajax) on the file input's change event.
  
No idle time, no backgrounding, no tab restoration, no "All Tabs" view -- the request fires within roughly a second of picking the file, in an active tab that was never suspended. It fails every time, with any file (confirmed down to a 113 KB PDF, so it isn't size-related), while the same flow works fine on Safari on iOS 18.

So the trigger doesn't seem limited to "file input data no longer readable after tab suspension" -- it also happens on a file that was just picked and is still fully live. Might be worth widening the scope of this bug, or reopening as separate if the root cause turns out to be different. Happy to attach our HAR (redacted) showing the Content-Length: 0 request if useful.

Follow-up to our earlier comments on bug 320904 (duplicate of this one) -- we found the actual root cause on our end, and it corrects something we said earlier.

We register a Service Worker on the site with a fetch handler along these lines:

  self.addEventListener('fetch', function(event) {
    event.respondWith(
      caches.match(event.request).then(function(response) {
        return response || fetch(event.request);
      })
    );
  });

This runs for every request on the origin, including our POST form submission. Since a POST never matches anything in the cache, it always falls through to fetch(event.request), which re-issues the intercepted Request. On Safari 26.5.2/26.6, when the intercepted request is a multipart/form-data POST containing a file part, the request that actually goes out over the network has Content-Length: 0 -- the body (file included) is lost during this re-fetch. Removing the Service Worker, or making it skip non-GET requests entirely, fixes it completely on our end.

This also corrects something in our earlier comment: we said the bug reproduced with JavaScript disabled in Safari settings, and concluded it wasn't related to any script. That conclusion was wrong -- a Service Worker that's already registered keeps running and intercepting fetch events regardless of that per-page JavaScript toggle, so our "no-JS" test never actually excluded the Service Worker from the picture. Once we understood that and looked specifically at what our Service Worker was doing with the request, we found this.

So the minimal repro isn't "any native file input breaks on this Safari version" as we originally described -- it's specifically: a Service Worker whose fetch handler re-issues an intercepted POST request via fetch(event.request) loses the request body on Safari 26.5.2/26.6. That's also consistent with bug 187461 ("Fetch using FormData with file doesn't go through Service Worker"), which we'd flagged as a maybe-related older bug in our first comment -- this may be the same underlying issue resurfacing, worth cross-checking.

FIX ON OUR SIDE:
We fixed it by having the fetch handler bail out early for any non-GET request, before it ever touches caches.match()/fetch():

  self.addEventListener('fetch', function(event) {
    if (event.request.method !== 'GET') {
      return;
    }
    event.respondWith(
      caches.match(event.request).then(function(response) {
        return response || fetch(event.request);
      })
    );
  });

Not calling event.respondWith() at all lets the browser handle the request natively, bypassing the Service Worker entirely for POSTs -- which also sidesteps the bug, since the request is no longer re-issued via fetch() from inside the worker. This is the correct behavior anyway (POST responses aren't cacheable), so it's a legitimate fix on our end regardless of the underlying WebKit bug, but it's worth noting for anyone hitting this: the underlying re-fetch-loses-the-body issue is still there in WebKit if a Service Worker actually needs to intercept and re-issue a POST.

[Per Arne Vollan]

*** This bug has been marked as a duplicate of bug 319985 ***