From fbfc5b01942efe1c00ad521981337a4b81b3855b Mon Sep 17 00:00:00 2001 From: Ricki Hirner Date: Tue, 6 May 2025 15:48:05 +0200 Subject: [PATCH 1/2] Only servers must check for subscription expiration --- content.mkd | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content.mkd b/content.mkd index a68b78a..b9d427a 100644 --- a/content.mkd +++ b/content.mkd @@ -306,11 +306,11 @@ HTTP/1.1 204 Unregistered ## Expiration -A client can specify an expiration date-time when they register a subscription. A server SHOULD take the requested expiration time into consideration, but MAY impose its own (often stricter) expiration rules, for instance to keep their database clean or because the client has specified an implausible late expiration. A server SHOULD allow subscriptions to be valid at least three days. However when the expiration is too far in the future, it becomes more probable that the subscription will become invalid or stale at some time. +When a client registers a subscription, it can request a specific expiration date-time. A server SHOULD take the requested expiration time into consideration, but MAY impose its own (often stricter) expiration rules. A server SHOULD allow subscriptions to be valid at least three days. When the expiration is too far in the future, it becomes more probable that the subscription will become invalid or stale at some time. -A client has to refresh its registrations regularly and before the expiration date to keep them working. It can expect that subscriptions usually stay valid until their expiration, although there may be special circumstances that cause all subscriptions to be reset, like when the server software is changed. +A client has to refresh its registrations regularly and before the expiration to keep them working. It can expect that subscriptions usually stay valid until their expiration, although there may be special circumstances that cause all subscriptions to be reset, like when the server software is changed. -Expired subscriptions MUST NOT be used anymore as chances are high that doing so would cause errors. +A server MUST NOT send notifications to expired subscriptions as chances are high that doing so would cause errors. From d3804653310f2cbbd720d9dbbe70e42f574a46f1 Mon Sep 17 00:00:00 2001 From: Ricki Hirner Date: Tue, 6 May 2025 15:52:55 +0200 Subject: [PATCH 2/2] Ignore invalid Push-Dont-Notify values --- content.mkd | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content.mkd b/content.mkd index b9d427a..7ac3191 100644 --- a/content.mkd +++ b/content.mkd @@ -306,11 +306,11 @@ HTTP/1.1 204 Unregistered ## Expiration -When a client registers a subscription, it can request a specific expiration date-time. A server SHOULD take the requested expiration time into consideration, but MAY impose its own (often stricter) expiration rules. A server SHOULD allow subscriptions to be valid at least three days. When the expiration is too far in the future, it becomes more probable that the subscription will become invalid or stale at some time. +When a client registers or updates a subscription, it can request a specific expiration date-time. A server SHOULD take the requested expiration time into consideration, but MAY impose its own (often stricter) expiration rules. A server SHOULD allow subscriptions to be valid at least three days. When the expiration is too far in the future, it becomes more probable that the subscription will become invalid or stale at some time. A client has to refresh its registrations regularly and before the expiration to keep them working. It can expect that subscriptions usually stay valid until their expiration, although there may be special circumstances that cause all subscriptions to be reset, like when the server software is changed. -A server MUST NOT send notifications to expired subscriptions as chances are high that doing so would cause errors. +A server MUST NOT send a notification to an expired subscription. @@ -365,6 +365,8 @@ Because URLs are not per se canonical, registration URLs MUST be provided in the Multiple values can be provided as a list and/or using multiple lines as described in {{Section 5.2 of RFC9110}}. If the asterisk is used, other values MUST NOT be sent. +A server MUST ignore invalid values. + Example 1: ~~~http-message