Hello,
I am investigating a WKWebView cookie reliability issue with WKWebsiteDataStore.default() / persistent website data, and I would like to request a supported public API to force persistent cookie durability.
We set persistent cookies from native code through the public WKHTTPCookieStore API:
let dataStore = WKWebsiteDataStore.default()
let cookieStore = dataStore.httpCookieStore
await cookieStore.setCookie(cookie)
The cookies have Max-Age / maximumAge set, so these are persistent cookies, not session-only cookies.
Reproduction pattern:
Use WKWebsiteDataStore.default().
Clear existing cookies.
Set a persistent cookie through WKHTTPCookieStore.setCookie.
After setCookie completes, terminate WebKit's NetworkProcess soon afterward.
Create or reuse a WKWebView with the same WKWebsiteDataStore.default().
Load a same-origin page or trigger a same-origin fetch.
I also have reproducible WebKit source-level test cases for this, in the style of TestWebKitAPI / WKHTTPCookieStore tests. The tests exercise persistent WKWebsiteDataStore.default() cookies, terminate the NetworkProcess after the cookie mutation, and then verify that a top-level load, same-origin fetch, and WKHTTPCookieStore cookie read can miss the cookie on an unpatched WebKit build.
Observed result:
The next top-level HTTP request, and sometimes a same-origin fetch, can omit the cookie that was just set. After the NetworkProcess is relaunched, WKHTTPCookieStore.allCookies() can also fail to show the recently set cookie.
If I wait long enough after the cookie mutation before terminating the NetworkProcess, the problem disappears. In local simulator testing, this lines up with CFNetwork appearing to debounce/coalesce persistent cookie writes in an approximately 2-to-10 second window. That makes this look like setCookie completion means the current NetworkProcess / CFNetwork cookie store accepted the cookie in memory, but the persistent cookie backing store has not necessarily been written yet. If the NetworkProcess dies before that delayed write, the replacement NetworkProcess appears to reload stale cookie state from disk.
This is especially painful for apps that bridge native authentication state into WKWebView. The app sees setCookie complete, assumes the cookie is ready, and then a later WebKit NetworkProcess termination can cause authenticated web requests to be sent without the expected auth cookie.
We believe that, at scale, this is a mechanism causing a baseline of about 5% of our HTTP requests, as measured by HAProxy, to lack cookies that should be present. We know those cookies should be present because we duplicate the same values as URLRequest headers under different keys, and the headers are present while the corresponding Cookie header entries are missing.
The API gap is that there does not appear to be a supported public equivalent of Android WebView's CookieManager.flush(). There is no public way for an app to say: "I just mutated persistent WKWebView cookies; please synchronously/asynchronously flush the persistent cookie store before I proceed."
Request:
Please expose a public flush API for persistent WKHTTPCookieStore / WKWebsiteDataStore cookies, for example an async API shaped like:
try await websiteDataStore.httpCookieStore.flush()
or:
try await websiteDataStore.flushCookies()
The important behavior would be:
after WKHTTPCookieStore.setCookie / deleteCookie completes, an app can explicitly request durability;
the flush completion should mean persistent cookie state has been handed to the backing persistent store, not merely accepted by the current NetworkProcess;
if flushing is impossible because the relevant process/state is gone, the API should fail or report that, rather than silently succeeding;
the API should be safe for App Store apps and should not require private SPI.
Question:
Are there any recommended supported patterns today for forcing persistent WKWebView cookies to reach durable storage after native WKHTTPCookieStore mutations?
Is there an official supported way to force or observe cookie durability for persistent WKWebsiteDataStore cookies? If not, is the recommended approach simply to re-apply critical cookies before loads and tolerate NetworkProcess loss as unrecoverable app-side state?
This issue is not just theoretical. It affects auth/session reliability when WebKit's NetworkProcess is terminated before the backing persistent cookie write completes. Apps can reduce unnecessary cookie churn, but without a flush API there is no supported way to close the durability window after setting important persistent cookies.
Topic:
Safari & Web
SubTopic:
General
1
0
47