Bug 249766

Summary:	Push to expired endpoint returns 200 still
Product:	WebKit	Reporter:	Andy <andy>
Component:	Service Workers	Assignee:	Nobody <webkit-unassigned>
Status:	RESOLVED WONTFIX
Severity:	Normal	CC:	beidson, nham, webkit-bug-importer, wilander
Priority:	P2	Keywords:	InRadar
Version:	Safari 16
Hardware:	Unspecified
OS:	Unspecified

Description Andy 2022-12-22 02:55:14 PST

Sending a Web Push notification to an old subscription gives no indication the subscription is old.

Example scenario:
User subscribes to push notifications
User removes the permission in safari settings (note: removes, not denies)
User subscribes to push notifications

Result:
Backend has two records of a subscription to that user, but only one is actually valid
When sending a notification to the first (expired) subscription, there is no indication the subscription has expired. This wastes bandwidth.
On other browsers, it will return a 40* error, allowing the server to delete the expired subscription


Admittedly, it may be a privacy issue to alert the server of an expired subscription. But the workaround (storing device details with a subscription to ensure each device has one subscription) also is a privacy concern

Comment 1 Radar WebKit Bug Importer 2022-12-22 13:15:34 PST

<rdar://problem/103648077>

Comment 2 Ben Nham 2023-01-04 12:46:05 PST

Thanks for your bug report. We reached out to the server team about this. There are a couple of things to consider here:

1. We do not guarantee that unsubscribing from Web Push will always result in a state where sending a push to the associated endpoint returns a 410 Gone. There are various error states which can cause the unsubscribe event to not be sent or processed successfully by the push server.

2. Even when the unsubscribe event is processed successfully by the push server, there is a non-deterministic delay between when the unsubscribe event is processed and when sending a push to the associated endpoint returns a 410 Gone. This delay is in place for privacy reasons.

If you want to ensure that you only track one push subscription per user session, you can send the current push subscription associated with the session to your backend when the user visits your website (e.g. by XHRing the result of PushManager.getSubscription to your backend). You can then use the current subscription data to prune any non-matching subscriptions.

Comment 3 Ben Nham 2023-01-04 17:13:41 PST

Also note that the delay described in (2) above is not specific to Web Push; it applies to the APNs service in general (so the delay also applies for native apps that use push). Some more explanation is here: https://developer.apple.com/forums/thread/670868.

The first sentence in that explanation isn't correct though; it should begin "On the HTTP/2 interface, you *may* see a 410 error", as explained by (1) above.