Independent submission R. Hirner
bitfire.at
6 May 2025
Push for WebDAV (WebDAV-Push)
draft-bitfire-webdav-push-00
Abstract
This document specifies a mechanism to timely notify WebDAV clients
when the content or properties of a resource or its members are
changed on the WebDAV server.
As a transport for such push notifications, it only specifies Web
Push (RFC 8030). It can however by design be used with other
transports as well.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. XML Element Namespace . . . . . . . . . . . . . . . . . . 5
2. Service Detection . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Push Properties . . . . . . . . . . . . . . . . . . . . . 6
3. Subscription Management . . . . . . . . . . . . . . . . . . . 9
3.1. Subscription Registration . . . . . . . . . . . . . . . . 9
3.1.1. Content Updates . . . . . . . . . . . . . . . . . . . 10
3.1.2. Property Updates . . . . . . . . . . . . . . . . . . 11
3.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Subscription Updates . . . . . . . . . . . . . . . . . . 14
3.3. Subscription Removal . . . . . . . . . . . . . . . . . . 14
3.4. Expiration . . . . . . . . . . . . . . . . . . . . . . . 14
4. Push Notification . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Push Message . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Suppressing Notifications . . . . . . . . . . . . . . . . 16
4.3. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Removal of Invalid Subscriptions . . . . . . . . . . . . 18
5. CalDAV/CardDAV . . . . . . . . . . . . . . . . . . . . . . . 18
6. Web Push Transport . . . . . . . . . . . . . . . . . . . . . 19
6.1. Subscription Registration . . . . . . . . . . . . . . . . 20
6.2. VAPID . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1. Key Rotation . . . . . . . . . . . . . . . . . . . . 21
6.3. Message Encryption . . . . . . . . . . . . . . . . . . . 22
6.4. Push Message . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
Hirner Experimental [Page 1]
WebDAV-Push May 2025
7.1. Security Context . . . . . . . . . . . . . . . . . . . . 23
7.2. Push Services . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Web Push . . . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 26
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction
*(This document is in work and subject of ongoing modification.)*
WebDAV-Push is intended as a tool for WebDAV [RFC4918] clients to get
notified about updates in resources (usually collections) in near
time so that they can refresh their views, perform synchronization
etc.
A client MUST NOT rely solely on WebDAV-Push, so it should also
perform regular polling like when WebDAV-Push is not available.
However if WebDAV-Push is available, the polling frequency can be
significantly reduced.
Typical use cases:
* A mobile app synchronizes calendars/address books with device-
local storage and wants to be notified on collection updates in
order to re-synchronize.
* A desktop file manager shows contents of a WebDAV collection and
wants to be notified on updates in order to refresh the view.
* A calendar Web app shows a CalDAV collection and wants to be
notified on updates in order to refresh the view.
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Overview
Hirner Experimental [Page 2]
WebDAV-Push May 2025
.--------------------. .--------------. .--------------------.
| WebDAV-Push Server | | Push Service | | WebDAV-Push Client |
'--------------------' '--------------' '--------------------'
Create subscription
.----------------------o
'---------------------->
Register subscription
<-------------------------------------------o
Content update notification
o------------------->*---------------------->
Figure 1: Basic WebDAV-Push Workflow
A WebDAV-Push server needs to
* advertise WebDAV-Push and relevant information (service
detection),
* manage subscriptions to resources (usually collections), and
* send push messages when a subscribed resource changes.
In order to manage subscriptions, a WebDAV server needs to
* provide a way for clients to subscribe to a resource (with
transport-specific information),
* provide a way for clients to unsubscribe from a resource, and
* handle expired or otherwise invalid subscriptions.
Notifications about updated resources have to be sent to all
subscribed clients over the respective push transports.
A WebDAV-Push client typically
* detects whether the server supports WebDAV-Push and which push
transports,
* connects to a push service (which is usually not operated by the
same party as the WebDAV server),
* subscribes to one or more resources on the server (with the data
received from the push service),
Hirner Experimental [Page 3]
WebDAV-Push May 2025
* receives push notifications that cause some client-side action
(like to refresh the view or run synchronization),
* re-subscribes to resources before the registrations expire,
* unsubscribes from resources when notifications are not needed
anymore.
WebDAV-Push is not restricted to a specific push transport. This
allows even upcoming, yet unknown push transports to be used with
WebDAV-Push. Push transport definitions can define extra properties
and additional processing rules.
WebDAV-Push implementations SHOULD implement at least the Web Push
transport (defined in Section 6). Ideally, other transports are
connected over a Web Push gateway instead of defining a new WebDAV-
Push transport.
1.3. Terminology
If parts of a term are in brackets, it means that those parts may or
may not be written together with the other parts. However it means
the same in any case.
Push notification push message or delivery of a push message
Push message Actual network message that is sent from the server
over a push transport to the client. Notifies the client that a
specific resource (identified by its push topic) has changed.
In Web Push context, a WebDAV-Push server can send a push message
(more exact, "request delivery of a push message") over the push
service by POSTing the message to the client's subscription URL.
Push service Infrastructure that implements a specific push
transport. The push service is the actual network service between
WebDAV-Push server and WebDAV-Push client.
For instance, if the push transport is Web Push is a Web app, the
push service would be provided by the vendor of the browser that
the client runs in.
(Push) subscription (URL) The information that the client needs to
provide to the server so that the server can send push
notifications. The server can POST a push message to that URL.
Hirner Experimental [Page 4]
WebDAV-Push May 2025
If the transport is Web Push, the term "(push) subscription (URL)"
as used in this document is equivalent to the Web Push term "push
resource".
(Push) topic Character sequence that identifies a WebDAV resource
for push purposes (unique per WebDAV server). A specific resource
could be reachable at different URLs, but it can only have one
push topic.
(Push) transport Protocol that defines an actual push mechanism. In
this document, Web Push is the only defined push transport (see
Section 6). However, WebDAV-Push may also be used with other push
transports like proprietary or yet unknown protocols. In that
case, it has to be specified how to use that protocol with WebDAV-
Push. A push transport typically involves a push service.
Web Push "Protocol for the delivery of real-time events to user
agents", defined by [RFC8030]. Usually implemented in browsers
(which means that major browser vendors provide their own push
services), but there are also other implementations like
[UnifiedPush]. Some parts (namely push message delivery from the
push service to the client) specify implementation details that
may be done by other means without changing the meaning of the RFC
for WebDAV-Push servers and clients.
There are also additional standards that can be considered to
belong to Web Push, especially VAPID ([RFC8292]) and Message
Encryption ([RFC8291]).
WebDAV-Push WebDAV-based protocol to notify clients about updates in
resource using a push transport (in contrast to polling).
Specified in this document.
(WebDAV-Push) client WebDAV client that supports WebDAV-Push, for
instance a CalDAV/CardDAV app on a mobile device
(WebDAV-Push) server WebDAV server (for instance a CalDAV/CardDAV
server) that implements WebDAV-Push
1.4. XML Element Namespace
When XML element names are used without namespace in this document,
they are in the WebDAV-Push namespace: https://bitfire.at/webdav-push
All XML elements defined by this document reside in this namespace.
The XML schema for the elements can be found in Appendix A.
Hirner Experimental [Page 5]
WebDAV-Push May 2025
To reference element names in another namespace, the {ns}element
syntax is used. For instance, {DAV:}prop means the prop XML element
in the DAV: namespace.
2. Service Detection
A server that supports WebDAV-Push MUST include "webdav-push" in the
DAV header of an OPTIONS response for any resource that supports
WebDAV-Push. The "webdav-push" value MUST indicate that all MUST-
level requirements of this document are met and all SHOULD-level
requirements are met except for a good reason.
Example:
OPTIONS /calendars/
Host: caldav.example.com
HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
DAV: 1, 2, access-control, calendar-access, webdav-push
Content-Length: 0
Here, the OPTIONS response contains "webdav-push" in the DAV header
to indicate that the resource supports the properties and operations
defined in this document.
2.1. Push Properties
To provide information about WebDAV-Push support, new properties are
defined. A server MUST provide the transports, topic and supported-
triggers properties for resources that support WebDAV-Push. A server
MUST NOT provide the topic and supported-triggers properties for
resources that don't support WebDAV-Push (for instance for non-
collection resources, if they're not supported).
The transports element lists available push transports. Within the
scope of this document, the only supported transport is web-push (see
Section 6). Although the property is defined on every Push-capable
resource, its value is usually the same for every resource on the
server.
The topic is a (server-wide) unique identifier for the resource. A
specific resource could be reachable with different URLs, but it can
have only one push topic. A server could for instance use a random
UUID or a canonical URL that won't change over the lifetime of the
resource.
Hirner Experimental [Page 6]
WebDAV-Push May 2025
The supported-triggers element MUST contain at least one of the
following elements:
* content-update if the resource supports push notifications on
content updates (see Section 3.1.1). It contains a {DAV:}depth
property that indicates the maximum supported depth.
* property-update if the resource supports push notifications on
property updates (see Section 3.1.2). It contains a {DAV:}depth
property that indicates the maximum supported depth.
A client can use WebDAV PROPFIND to retrieve these properties.
Example:
Hirner Experimental [Page 7]
WebDAV-Push May 2025
PROPFIND https://example.com/webdav/collection/
HTTP/1.1 207 Multi-Status
/webdav/collection/
BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs
O7M1nQ7cKkKTKsoS_j6Z3w
1
0
In this case, the queried collection supports WebDAV-Push in general
and thus has a push topic. It supports the Web Push transport and
provides a VAPID public key. Push notifications are supported for
content updates of internal members and on property updates of the
collection itself.
The comment shows how support for some other (not yet defined)
transport could be advertised together with additional specific
information that is required to use it.
Hirner Experimental [Page 8]
WebDAV-Push May 2025
3. Subscription Management
3.1. Subscription Registration
To subscribe to a resource, the client sends a POST request with
Content-Type: application/xml to the resource it wants to subscribe.
The root XML element of the XML body is push-register and can be used
to distinguish between WebDAV-Push and other requests.
The push-register element contains:
* exactly one subscription element, which contains all information
the server needs to send a push message,
* exactly one trigger element to specify the type of updates the
client wants to be notified about, and
* an optional expires element that contains the requested expiration
time in the IMF-fixdate format (as defined in Section 5.6.7 of
[RFC9110]).
The subscription element specifies a subscription that shall be
notified on updates and contains exactly one element with details
about a specific subscription type. Within the scope of this
document, only the web-push-subscription child element is defined
(see Section 6).
To specify which updates the client wants to be notified about, it
uses the trigger element, which itself can contain:
* A content-update element to indicate the client's interest in
notifications when the contents of the subscribed resource or its
members change ("content update").
* A property-update element to indicate the client's interest in
notifications when the WebDAV properties of the subscribed
resource or its members change ("property update").
Hirner Experimental [Page 9]
WebDAV-Push May 2025
WebDAV-Push is intended more as a helpful tool to speed up things
(like synchronization) than a strict query processor. So
subscriptions are processed in a relaxed way: the server does its
best to fulfill the request, but if a certain trigger is not
available, it's downgraded or ignored instead of rejected with an
error response. If a client needs to know which triggers are
supported, it can use PROPFIND with supported-triggers. A client
MUST expect the server to downgrade or ignore certain triggers when
they're not (fully) supported, and MUST be prepared to receive an
error when it registers a subscription with only unsupported
triggers.
3.1.1. Content Updates
A "content update" occurs when the subscribed resource or a member is
changed or removed, as defined in Section 3.5 of [RFC6578].
Typically, this is the case when the resource itself is modified or
removed, or when a member is added or removed or its contents are
modified. If the server supports [RFC6578], a content update of a
collection usually implies that the {DAV:}sync-token changes.
The content-update element contains a {DAV:}depth element that
specifies whether the client is interested
* only in content updates of the subscribed resource (depth: 0),
* only in content updates of the subscribed resource and its
internal members (depth: 1), or
* in content updates of the subscribed resource and its members
(depth: infinity).
A content update of a collection itself (not of a member) only occurs
when the collection has an entity body that is returned by GET and
that body changes. A server MAY ignore such changes and not send
notifications in that case.
A server SHOULD support content update notifications with a depth of
at least 1 for every Push-capable collection.
If the subscribed resource doesn't support the content update trigger
with the requested depth, the server MUST fall back to the lowest
supported value instead. If the content update trigger isn't
supported for the subscribed resource at all, it MUST be ignored.
Hirner Experimental [Page 10]
WebDAV-Push May 2025
In case the depth is infinity, the limitations described in
Section 3.3 of [RFC6578] apply: notifications about changes in
members which are not supported by the DAV:sync-collection report may
not be sent.
3.1.2. Property Updates
A "property update" occurs when the WebDAV properties of the
subscribed resource or its members are modified. Properties update
notifications are controlled by two elements within the property-
update element:
1. The {DAV:}depth element specifies whether the client is
interested
* only in property updates of the subscribed resource (depth:
0),
* only in property updates of the subscribed resource and its
internal members (depth: 1), or
* in property updates of the subscribed resource and its members
(depth: infinity).
If the subscribed resource doesn't support the property update
trigger with the requested depth, the server MUST fall back to
the lowest supported value instead. If the property update
trigger isn't supported for the subscribed resource at all, it
MUST be ignored.
In case the depth is infinity, the limitations described in
Section 3.3 of [RFC6578] apply: notifications about changes in
members which are not supported by the DAV:sync-collection report
may not be sent.
2. The optional {DAV:}prop element (as used in a PROPFIND request)
specifies a list of properties that the client is interested in.
If the {DAV:}prop element is empty or not present, the server
chooses a list of properties that it considers to be useful for
the client. If the {DAV:}prop element is present and contains
properties for which property update notifications are not
supported, the server MUST ignore those unsupported properties.
Also, a server MAY ignore the contents of a {DAV:prop} element at
all and treat it like if it was empty or not present.
Hirner Experimental [Page 11]
WebDAV-Push May 2025
Neither a server nor a client SHOULD use property update
notifications for properties that automatically change on a
content update, like {DAV:}getetag, {DAV:}getlastmodified and
{DAV:}sync-token, because this would implicitly cause a property
update for every content update. Notifications about content
updates should instead be requested/sent explicitly as content
update notifications.
The removal of a resource, including the subscribed resource, is not
considered as a property update but as a content update.
3.1.3. Response
Allowed response codes:
* 201 if the subscription was registered and the server wants to
return additional information, like encryption details that are
only valid for this subscription. The format of these details is
specified by the respective transport definition.
* 204 if the subscription was registered without additional
information
* 403 with precondition invalid-subscription when the request
doesn't contain a valid subscription
* 403 with precondition push-not-available if WebDAV-Push is not
available for this resource or if the user is not allowed to
register a push subscription for it
* 403 with precondition no-supported-trigger when the request
doesn't contain a trigger or when all requested triggers are
ignored (because they're not supported)
* other response code with usual HTTP/WebDAV semantics
When a subscription is registered the first time, the server creates
a canonical URL that identifies that registration (registration URL)
which can be used to remove the subscription. The server MUST send
an absolute registration URL in the Location header.
The server MUST return a HTTP Expires header (as defined in
Section 5.3 of [RFC9111]) in the IMF-fixdate format with the actual
expiration date on the server, which may be shorter than the
expiration requested by the client.
Example 1 (successful registration):
Hirner Experimental [Page 12]
WebDAV-Push May 2025
POST https://example.com/webdav/collection/
Content-Type: application/xml; charset="utf-8"
https://up.example.net/yohd4yai5Phiz1wi
aes128gcm
BCVxsr7N_eNgVRqvHtD0zTZsEc6-VV-JvLexhqUzORcxaOzi6-AYWXvTBHm4bjyPjs7Vd8pZGH6SRpkNtoIAiw4
BTBZMqHH6r4Tts7J_aSIgg
infinity
0
Wed, 20 Dec 2023 10:03:31 GMT
HTTP/1.1 204 No Content
Location: https://example.com/webdav/subscriptions/io6Efei4ooph
Expires: Wed, 02 Oct 2024 07:28:00 GMT
Example 2: A client registers a content update trigger with infinite
depth and a property update trigger with a depth of 1, but the
collection supports only content update triggers with a depth of 1
and doesn't support the property update trigger at all, it registers
the subscription and responds with 201. Notifications will then only
be sent on content updates with a depth of 1 (trigger downgraded by
server). On property updates, notifications will not be sent
(trigger ignored by server).
Example 3: A client registers a property update trigger with a depth
of 0 and the collection doesn't support property update triggers at
all, the server ignores the trigger. So all triggers of the request
are ignored and the server responds with 403 with no-supported-
trigger.
Hirner Experimental [Page 13]
WebDAV-Push May 2025
3.2. Subscription Updates
Every subscription has a transport-specific unique identifier (the
push resource in case of Web Push).
A server MUST NOT register a subscription with the same identifier
multiple times for the same resource. Instead, when a client wants
to register a subscription with an identifier that is already
registered for the requested resource, the server MUST update the
registration with the given details and the expiration date.
The response is the same as for subscription registration.
3.3. Subscription Removal
A client can explicitly unsubscribe from a resource by sending a
DELETE request to the previously acquired registration URL.
Allowed response codes:
* 204 if the registered subscription was removed.
* 404 if the registration URL is unknown (or expired).
* other response code with usual HTTP/WebDAV semantics
Sample request:
DELETE https://example.com/webdav/subscriptions/io6Efei4ooph
HTTP/1.1 204 Unregistered
3.4. Expiration
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.
Hirner Experimental [Page 14]
WebDAV-Push May 2025
A server MUST NOT send a notification to an expired subscription.
4. Push Notification
A WebDAV-Push server MUST notify registered subscriptions of a
subscribed resource:
* on a _content update_, if this was requested during subscription
registration, and
* on a _property update_, if this was requested during subscription
registration.
In case of the Web Push transport, this happens over a POST request
to the subscription (push resource).
4.1. Push Message
The push message body consists of a push-message element, which
contains information about the affected resource:
* a topic element with the push topic (except for VAPID key rotation
messages, see Section 6.2.1),
* a content-update element in case of a content update, and/or
* a property-update element in case of a property update.
The content-update element of a push message SHOULD contain a
{DAV:}sync-token element so that a client can ignore the push message
when it already knows the latest state.
The property-update element of a push message is usually empty
(except for VAPID key rotation messages).
Example:
O7M1nQ7cKkKTKsoS_j6Z3w
http://example.com/sync/10
Hirner Experimental [Page 15]
WebDAV-Push May 2025
Here, both the contents and the properties of the resource (or its
members, depending on the registered trigger) with topic
O7M1nQ7cKkKTKsoS_j6Z3w have changed. The new sync-token (after the
change) is http://example.com/sync/10.
4.2. Suppressing Notifications
A client may not want to receive push notifications for a change that
it induces itself. It can indicate this with the Push-Dont-Notify
header field, which is sent together with the request that causes the
change.
Header name: "Push-Dont-Notify"
Value syntax in ABNF with #rule extension as defined in Section 5.6.1
of [RFC9110]:
Push-Dont-Notify = 1#(quoted-registration-url) / "*"
quoted-registration-url = quoted-string
; absolute push registration URL
In the context of the requested operation, a server MUST NOT send
push notifications to the explicitly given subscription URLs of the
Push-Dont-Notify header, and it SHOULD NOT send any push
notifications when the asterisk value (*) is used.
Because URLs are not per se canonical, registration URLs MUST be
provided in the exact form as it was originally provided by the
server in the Location header.
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:
PUT /file.txt HTTP/1.1
Host: www.example.com
Push-Dont-Notify: "https://example.com/webdav/subscriptions/io6Efei4ooph"
[…]
HTTP/1.1 201 Created
Hirner Experimental [Page 16]
WebDAV-Push May 2025
In this example, the client requests that the server doesn't send a
push notification for the change in file.txt to the mentioned
subscription.
Example 2:
DELETE /file.txt HTTP/1.1
Host: www.example.com
Push-Dont-Notify: *
[…]
HTTP/1.1 204 No Content
Here the client requests that the server doesn't send any push
notification in the context of the deletion.
4.3. Rate Limiting
It's possible that a lot of changes occur within a short period of
time (like an upload of many contacts or a mass-change of events,
especially for a collection with a lot of subscriptions). This can
lead to problems when every change results in a push message:
* The push server has to send a lot of messages (number of changes
times number of subscriptions), which means high load and traffic.
* The push service receives a lot of messages within a short period
of time (spiky traffic, which should be avoided) and may throttle
or deny delivery.
* Push clients receive a lot of unnecessary notifications, because
they'd only need one after all changes are done. Especially for
mobile clients that also means a lot of useless battery and
network usage.
A server SHOULD take measures to avoid such problems. These can
include:
* to send push messages asynchronously (so that for instance a PUT
doesn't block until all notifications are sent),
* to impose a rate limit for push messages,
* to delay push messages (usually for a short time),
* to merge/omit push messages.
Hirner Experimental [Page 17]
WebDAV-Push May 2025
Such measures SHOULD NOT change the overall meaning of the push
notifications so that the client can still perform its desired
action. For instance, of a series of push messages that contain only
content updates and occur shortly after each other, all but the last
message can be omitted (the messages are _merged_ into a single one).
If one of the push messages signals a property update, it can't be
just omitted because the client then wouldn't know that a property
update happened. So in that case the server could either send two
messages (one merged message for the content updates and one for the
property update) or even better a single push message that signals
both the content and the property update.
A client MAY use the Push-Dont-Notify: * header to reduce the number
of push messages when desired (for instance, for all requests in a
batch except the last one). However it should be aware that if the
last operation fails, then no push notification is sent at all; so
this should be used only when really necessary.
4.4. Removal of Invalid Subscriptions
A WebDAV-Push server SHOULD remove invalid subscriptions (encountered
when trying to sending a push notification) at some time.
An invalid subscription is a subscription that push notifications
can't be delivered to. Usually the push service returns an HTTP
error code like 404 when it receives a notification for an invalid
subscription. There may also be other conditions that render a
subscription invalid, like a non-resolvable hostname or an encryption
error.
A server could use some logic like remembering the last successful
delivery plus some tolerance interval to defer removal of an invalid
subscription. Doing so will make WebDAV-Push more reliable in case
of temporary problems and avoid temporal "holes" between subscription
removal and re-registration.
5. CalDAV/CardDAV
WebDAV-Push can be used with CalDAV [RFC4791] and CardDAV [RFC6352]
to provide short-time update notifications when collections
(calendars, address books) or entries (contacts, events, …) change.
Depending on the features of a CalDAV/CardDAV client, it could for
instance subscribe to:
* content updates of a home-set to become notified about new
collections,
Hirner Experimental [Page 18]
WebDAV-Push May 2025
* content updates of a collection (usually with a depth of 1) to
become notified about modified entries,
* property updates of a collection (usually with a depth of 0) to
become notified about changes of properties like display name,
calendar color and access permissions,
* property updates (for instance display name) of a principal to
update real names of collection owners.
A CalDAV/CardDAV server that supports WebDAV-Push SHOULD support:
* content updates with a {DAV:}depth of at least 1 on
- calendar-home-set and addressbook-home-set collections,
- calendars and address books (collections which have a
{DAV:}resourcetype of {CALDAV:}calendar or
{CARDDAV:}addressbook),
- scheduling inbox and outbox collections (collections which have
a {DAV:}resourcetype of {CALDAV:}schedule-inbox or
{CALDAV:}schedule-outbox as defined in Section 2 of [RFC6638]);
* property updates with a {DAV:}depth of at least 0 on
- calendars and address books,
- principals (collections with have a {DAV:}resourcetype of
{DAV:}principal as defined in Section 4 of [RFC3744]).
6. Web Push Transport
WebDAV-Push can be used with Web Push [RFC8030] as a transport to
deliver WebDAV-Push notifications directly to compliant user agents,
like Web browsers which come with their own push service
infrastructure.
When the Web Push transport is used for WebDAV-Push,
* [RFC8030] defines how to generate subscriptions and send push
messages,
* the WebDAV-Push server acts as Web Push application server,
* the WebDAV client acts as Web Push user agent.
Corresponding terminology:
Hirner Experimental [Page 19]
WebDAV-Push May 2025
* (WebDAV-Push) push subscription ↔ (Web Push) push resource
* (WebDAV-Push) push server ↔ (Web Push) application server
* (WebDAV-Push) push client ↔ (Web Push) user agent
Message encryption (Section 6.3) MUST be used. VAPID (Section 6.2)
SHOULD be used. (If other methods to provide a security context for
Web Push become established, those can be used and necessary WebDAV
properties shall be added to this document.)
A server that supports the Web Push transport MUST list the web-push
element in the transports property.
.--------------------. .--------------. .--------------------.
| | | Web Push | | |
| WebDAV-Push Server | | Service | | WebDAV-Push Client |
'--------------------' '--------------' '--------------------'
Get VAPID public key
.-------------------------------------------o
'------------------------------------------->
Create restricted subscription
.----------------------o
'---------------------->
Register subscription (with encryption)
<-------------------------------------------o
Content/property update notification
o---(encrypted)----->*------(encrypted)----->
Figure 2: WebDAV-Push over Web Push with VAPID and Message Encryption
6.1. Subscription Registration
To register a Web Push subscription, the subscription element of the
push-register request contains exactly one web-push-subscription.
The web-push-subscription element represents the public information
of a Web Push subscription that is shared with the WebDAV-Push
server.
It contains exactly one push-resource element, which specifies the
absolute URI that identifies the endpoint where Web Push
notifications are sent to.
Hirner Experimental [Page 20]
WebDAV-Push May 2025
A Web Push subscription is uniquely identified by its push resource.
6.2. VAPID
VAPID [RFC8292] binds push subscriptions to a specific WebDAV-Push
server.
A WebDAV-Push server that supports VAPID stores a key pair. It
exposes an additional transport property vapid-public-key within the
web-push element, which contains the VAPID public key in uncompressed
form and base64url encoded. The attribute type="p256ecdsa" MUST be
added to allow different key types in the future. See Section 2.1
for an example.
If the server provides a VAPID public key, the client MUST use that
key to create a restricted subscription at the push service (except
when the used push service doesn't support VAPID).
A client can expect the VAPID public key to be the same for all
resources on the server.
When the server provides a VAPID public key, it MUST include a
corresponding Authorization header when sending a push message to
prove its identity to the push service.
6.2.1. Key Rotation
The VAPID public key can sometimes change, either intentionally (key
rotation) or for instance when the server or user data is moved to
another machine. When the VAPID key has changed, a client has to
create new restricted subscriptions because the old ones are bound to
the old key and thus don't work anymore.
When a server that changes its VAPID key is able to notify clients
with the old VAPID key before switching, it SHOULD send a key
rotation push message to every distinct active subscription.
A key rotation push message is a push message that only contains a
property-update that includes a {DAV:}prop property with the
transports property like this:
Hirner Experimental [Page 21]
WebDAV-Push May 2025
A client that receives a key rotation push message MUST assume that
the last known VAPID key isn't valid anymore. So in order to restore
Push functionality, it has to query the new VAPID key, create a new
subscription and register it again.
However because it's possible that the VAPID key changes without
possibility to notify the clients with the old key, clients are
advised to verify the VAPID key regularly.
6.3. Message Encryption
Message encryption hides details of push messages from the push
services. Before creating the subscription, the client generates a
key pair as defined in [RFC8291].
When the client then registers this subscription at the server, it
includes these subscription properties:
* content-encoding – how the encrypted content is encoded; currently
only aes128gcm is supported
* subscription-public-key – public key of the user agent's key pair
in uncompressed form and base64url encoded; attribute
type="p256dh" MUST be added to allow different key types in the
future
* auth-secret – authentication secret
These properties are bound to the subscription (which is identified
by the push resource). A server doesn't need to store these
properties for every registration, but only once for the
subscription.
The server uses these data to encrypt the payload before sending it
to the push service. The client then decrypts the payload again.
Hirner Experimental [Page 22]
WebDAV-Push May 2025
6.4. Push Message
The push message is delivered via POST to the push resource, with
Content-Type: application/xml; charset="UTF-8".
The server MAY send the push message with a Topic header so that an
undelivered push message can be replaced by an updated one. The
server MUST ensure that the meaning doesn't change when a push
message is potentially replaced. The Topic header is visible to the
push service, so its value MUST NOT contain sensitive information.
The server MAY use the Urgency header to set the priority of the push
message. For instance, a CalDAV server may send push notifications
for new/changed events with alarms that are scheduled within the next
15 minutes with Urgency: high so that users receive the alarm as soon
as possible. Updates that are not that time-critical, for instance
in slowly changing collections like a holiday calendar could be sent
with Urgency: low.
7. Security Considerations
7.1. Security Context
WebDAV-Push operates within the usual security context of WebDAV. A
server usually restricts WebDAV access to authorized users. It makes
sense to apply the same restrictions to WebDAV-Push operations (like
subscription registration). It's however up to the server to define
which WebDAV-Push operations are allowed and under which conditions.
If a request is denied because of wrong authentication or security
restrictions, the correct HTTP/WebDAV status codes MUST be used
(usually 401 or 403).
WebDAV-Push SHOULD only be advertised to clients which are actually
allowed to use it.
A server SHOULD restrict all requests to the access and knowledge
scope of the currently authenticated user. For instance, when a
subscription is registered, the registration can be associcated with
the current user. The server should then restrict further usage of
the registration URL to that user. The server should deny to update/
delete the registration of another user, or to use a registration URL
created by another user in the Push-Dont-Notify header.
Hirner Experimental [Page 23]
WebDAV-Push May 2025
7.2. Push Services
Even when push messages are end-to-end-encrypted, push services can
relate clients over metadata and heuristics. For instance, clients
which are at the same time notified by a specific WebDAV-Push server
have probably subscribed the same resource. Push services could also
create a map of which clients are registered to which WebDAV-Push
servers.
The value of a potential Topic header of a push message is not
covered by end-to-end encryption because it's require the push
service to process it.
7.3. Web Push
When using the Web Push transport, the general requirements from
Section 8 of [RFC8030] apply, especially:
* HTTP over TLS MUST be used for all communications.
* Mechanisms that provide end-to-end confidentiality, integrity and
data origin authentication MUST be used.
8. References
8.1. Normative References
[RELAXNG] The Organization for the Advancement of Structured
Information Standards, "RELAX NG Specification", December
2001, .
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007,
.
[RFC6578] Daboo, C. and A. Quillaud, "Collection Synchronization for
Web Distributed Authoring and Versioning (WebDAV)",
RFC 6578, DOI 10.17487/RFC6578, March 2012,
.
Hirner Experimental [Page 24]
WebDAV-Push May 2025
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291,
DOI 10.17487/RFC8291, November 2017,
.
[RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server
Identification (VAPID) for Web Push", RFC 8292,
DOI 10.17487/RFC8292, November 2017,
.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
.
8.2. Informative References
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV) Access
Control Protocol", RFC 3744, DOI 10.17487/RFC3744, May
2004, .
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
DOI 10.17487/RFC4791, March 2007,
.
[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed
Authoring and Versioning (WebDAV)", RFC 6352,
DOI 10.17487/RFC6352, August 2011,
.
[RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
.
Hirner Experimental [Page 25]
WebDAV-Push May 2025
[UnifiedPush]
"UnifiedPush", .
Appendix A. XML Schema
This XML schema formally defines the XML elements used by this
document and is expressed in [RELAXNG].