[Bug]: CapacitorCookies does not respect subsequent response Set-Cookie headers on iOS

[SaebAmini]

Capacitor Version

Capacitor Doctor

Latest Dependencies:

@capacitor/cli: 7.2.0
@capacitor/core: 7.2.0
@capacitor/android: 7.2.0
@capacitor/ios: 7.2.0

Installed Dependencies:

@capacitor/cli: 7.2.0
@capacitor/android: 7.2.0
@capacitor/core: 7.2.0
@capacitor/ios: 7.2.0

Other API Details

Platforms Affected

• iOS
• Android
• Web

Current Behavior

After enabling CapacitorCookies, I'm observing this faulty behaviour with cookie handling on iOS devices:

• When the response first returns a Set-Cookie header, it is persisted correctly (verified that it shows up under Safari Storage > Cookies when inspected).
• Subsequent server responses returning a Set-Cookie for the same cookie, are ignored and the persisted cookie doesn't update. This results in the old stale cookie being sent back to the server on subsequent requests.

Some of the scenarios this issue blocks:

• Server simply wanting to clear a cookie (e.g. common on logging out). Currently the cookie persists.
• If the user signs in with another account it keeps sending the previous user's cookie.
• Server wanting to update the cookie as a result of updated claims etc., or simply updating the expiry date.

Other notes:

• This doesn't happen on an Android device based on my testing, so seems to be a bug just on the iOS implementation.
• This behaviour doesn't happen with the normal "unpatched" document.cookie (i.e. when not having CapacitorCookies enabled)
• When I manually delete the cookie, then the subsequent responses with Set-Cookie are properly processed. This leads me to believe there is a bug in the iOS implementation somewhere that cannot handle an existing cookie.

Expected Behavior

Every Set-Cookie header should be processed, and update existing cookie if one exists.

Project Reproduction

Can provide later if absolutely necessary, but the explanation is clear.

Additional Information

No response

[SaebAmini]

Reading #7262, I think the issues could be because of the same root cause.

[davidbeaton]

We also have been seeing this issue for quite some time and have had to work around it in a not ideal way that we would eventually like to remove. I opened #6591 a few years ago which appears to be the same root cause as this new opened issue

#6591