WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
249766
Push to expired endpoint returns 200 still
https://bugs.webkit.org/show_bug.cgi?id=249766
Summary
Push to expired endpoint returns 200 still
Andy
Reported
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
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2022-12-22 13:15:34 PST
<
rdar://problem/103648077
>
Ben Nham
Comment 2
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.
Ben Nham
Comment 3
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug