One document matched: draft-thomson-webpush-http2-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-thomson-webpush-http2-01">
<front>
<title abbrev="HTTP Web Push">
Generic Event Delivery Using HTTP Push
</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address>
<postal>
<street>331 E Evelyn Street</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>US</country>
</postal>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<date year="2014"/>
<area>RAI</area>
<workgroup>WEBPUSH</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>HTTP</keyword>
<keyword>HTTP2</keyword>
<keyword>Push</keyword>
<keyword>WebPush</keyword>
<abstract>
<t>
A simple protocol for the delivery of realtime events to clients is described. This scheme
uses HTTP/2 push.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Mobile computing devices are increasingly relied upon for a great many applications. Mobile
devices typically have limited power reserves, so finding more efficient ways to serve
application requirements is an important part of any mobile platform.
</t>
<t>
One significant contributor to power usage mobile devices is the radio. Radio
communications consumes a significant portion of the energy budget on a wirelessly connected
mobile device.
</t>
<t>
Many applications require continuous access to network communications so that real-time
events - such as incoming calls or messages - can be conveyed (or "pushed") to the user in a
timely fashion. Uncoordinated use of persistent connections or sessions from multiple
applications can contribute to unnecessary use of the device radio, since each independent
session independently incurs overheads. In particular, keep alive traffic used to ensure
that middleboxes do not prematurely time out sessions, can result in significant waste.
Maintenance traffic tends to dominate over the long term, since events are relatively rare.
</t>
<t>
Consolidating all real-time events into a single session ensures more efficient use of
network and radio resources. A single service consolidates all events, distributing those
events to applications as they arrive. This requires just one session, avoiding duplicated
overhead costs.
</t>
<t>
The <xref target="API">Web Push API</xref> describes an API that enables the use of a
consolidated push service from web applications. This expands on that work by describing a
protocol that can be used to:
<list style="symbols">
<t>
request the delivery of an event to a device,
</t>
<t>
register a new device,
</t>
<t>
create new event delivery channels, and
</t>
<t>
monitor for new events.
</t>
</list>
</t>
<t>
This is intentionally split into these two categories because requesting the delivery of
events is required for immediate use by the Web Push API. The registration, management and
monitoring functions are currently fulfilled by proprietary protocols; these are adequate,
but do not offer any of the advantages that standardization affords.
</t>
<t>
The monitoring function described in this document is intended to be replaceable, enabling
the use of monitoring schemes that are better optimized for the network environment and the
device. For instance, using notification systems like the GSM Short Message Service (SMS)
can take advantage of the native paging capabilities of a cellular network, avoiding the
ongoing maintainence cost of a persistent TCP connection.
</t>
<t>
This document intentionally does not describe how a push server is discovered. Discovery of
push servers is left for future efforts, if it turns out to be necessary at all. Devices
are expected to be configured with a push server URL.
</t>
<t>
Similarly, discovery of support for and negotiation of use of alternative monitoring schemes
is left to documents that extend this basic protocol.
</t>
<section anchor="terminology" title="Conventions and Terminology">
<t>
In cases where normative language needs to be emphasized, this document falls back on
established shorthands for expressing interoperability requirements on implementations:
the capitalized words "MUST", "MUST NOT", "SHOULD" and "MAY". The meaning of these is
described in <xref target="RFC2119"/>.
</t>
<t>
This document will use the terminology from <xref target="API"/>, though "application"
will be used in preference to "webapp", since the described protocols are not restricted
to web use. This document introduces the term "device", which refers to the consumer of
push messages.
</t>
</section>
</section>
<section title="Overview">
<t>
A general model for push services includes three basic actors: a device, a push server, and
an application.
</t>
<figure>
<artwork><![CDATA[
+-----------+ +-------------+ +-------------+
| Device | | Push Server | | Application |
+-----------+ +-------------+ +-------------+
| | |
| Register | |
|--------------------->| |
| Monitor | |
|<====================>| |
| Get Channel | |
|--------------------->| |
| Provide Channel |
|-------------------------------------------->|
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
]]></artwork>
</figure>
<t>
At the very beginning of the process, the device registers with the push server. This
establishes a shared session between the device and push server that will be used to
aggregate push messages from all applications that the device interacts with.
</t>
<t>
The registration response includes details on how the device is expected to monitor for
incoming push messages. This document describes one such mechanism, though more efficient
means of monitoring could be optionally defined (and this is expressly permitted).
</t>
<t>
A registration after creation has no channels associated with it. New channels can be
requested by the device and then distributed to applications. It is expected that devices
will distribute a different channel to each application, with the potential for multiple
channels being provided to the same application.
</t>
<t>
Applications use channels to deliver push messages to devices, via the push server.
</t>
<t>
Both registrations and channels have a limited lifetime. These will need to be refreshed or
replaced over time.
</t>
</section>
<section anchor="push" title="Delivering Push Messages">
<t>
A push channel is identified with an <xref target="RFC7230">HTTP URI</xref>. An application
can request the delivery of a push message by sending an HTTP PUT request to this URI,
including the push message in the body of the request.
</t>
<t>
A push server can acknowledge the end-to-end delivery of a push message by responding with a
200 (OK) status code. A push server that stores the message for later delivery (see <xref
target="store"/>) could respond with a 202 (Accepted) status code to indicate that the
message was stored, but not delivered.
</t>
</section>
<!-- TODO determine if we want this...
<section title="Responding to Push Messages">
<t>
A server that wishes to enable end-to-end communication between a device and application
could use a link relation of "replies" to provide a location where the device can provide a
response. The server can wait for some time for this to be populated and then use the
contents of this to generate the response to the push message.
That generates a lot of issues. You no longer can have arbitrary content-types, you have to
carry that funny HTTP message content type so that the client can see all the header fields
and provide them. It's pretty ugly.
</t>
</section>
-->
<section anchor="register" title="Registering">
<t>
A device that wishes to establish a new or replacement registration sends an HTTP POST
request to its configured push server URL. The request contains no entity body.
</t>
<t>
The push server creates a new registration in response to this request, creating two new
resources and allocating an HTTP URI for each. These URIs are included in <xref
target="RFC5988">link relations</xref> that are included in Link header fields in the
response.
<list style="hanging">
<t hangText="monitor:">
A link relation of type "...:push:monitor" <cref>pick a URN base and register it (RFC
3688)</cref> includes the URL of a resource that the device can monitor for events.
Monitoring is described in <xref target="monitor"/>.
</t>
<t hangText="channel:">
A link relation of type "...:push:channel" includes a URL of a resource where the device
can create new channels. Creating channels is described in <xref target="channel"/>.
</t>
</list>
The push server includes the "monitor" link relation in a Location header field.
</t>
<t>
The push server MUST include expiration information in the response to this request in
either the Expires header field, or by setting a "max-age" parameter on a Cache-Control
header field. The Cache-Control header field MUST include the "private" directive <xref
target="RFC7235"/>.
</t>
<t>
The push server SHOULD also provide the "channel" link and expiration information in
response to requests to the "monitor" resource.
</t>
<t>
A device MUST support the 307 (Temporary Redirect) status code <xref target="RFC7231"/>,
which can be used by a push server to redistribute load at the time a registration is
created.
</t>
</section>
<section anchor="channel" title="Channels">
<t>
A client sends a POST request to the "channel" resource to create a new channel.
</t>
<t>
A response with a 201 status code includes the channel URI in the Location header field.
</t>
<t>
A channel can expire. Servers indicate this using the Expires header field, or by setting a
"max-age" parameter on a Cache-Control header field.
</t>
<t>
A client can explicitly delete a channel by sending a DELETE request to channel URI.
</t>
</section>
<section anchor="monitor" title="Monitoring and Receiving Push Messages">
<t>
A device monitors for new events by making a GET request to the monitor resource. The
server does not respond to these request, it instead uses <xref
target="I-D.ietf-httpbis-http2">server push</xref> to send the contents of push messages as
applications send them.
</t>
<t>
Each push message consists of a synthesized GET request to the channel URI that was the
target of the push. The response body is the entity body from the PUT request.
</t>
<t>
A device can request the monitor resource immediately by including a <xref
target="RFC7240">Prefer header field</xref> with a "wait" parameter set to "0". This allows
clients to rapidly check for any missed messages. Clients can check the status of
individual channels by sending GET requests to the channel URI.
</t>
<t>
A server that wishes to redistribute load can do so using the alternative services
mechanisms that are part of HTTP/2 <xref target="I-D.ietf-httpbis-alt-svc"/>. The ALTSVC
frame type allows for redistribution of load whilst retaining the same monitor resource.
Once a device has established a replacement connection, it can notify the server of imminent
shutdown using a GOAWAY frame, which allows the server to respond to the long-standing GET
request and gracefully shut down the connection. This allows for seamless migration between
servers.
</t>
</section>
<section anchor="store" title="Store and Forward Operation">
<t>
Push servers are not obligated to store messages for any time. If a client is not actively
monitoring for push messages, messages can be lost.
</t>
<t>
Push servers can store messages for some time to allow for limited recovery from transient
faults. If a message is stored, but not delivered, the push server can indicate the
probable duration of storage by including expiration information in the response to the push
request.
</t>
<t>
Messages that were stored and not delivered to a client MAY be delivered when a client
commences monitoring. These messages should include a Last-Modified header field. If a
server stores push messages, a GET request to a channel URI returns the last message sent by
an application to that channel.
</t>
<t>
Push servers that store push messages might need to limit the size of push messages to avoid
being subject to overloading. Push servers that don't store can stream the payload of push
messages to devices. This can use HTTP/2 flow control to limit the state commitment this
requires. However, push servers MAY place an upper limit on the size of push messages that
they permit.
</t>
</section>
<section title="IANA Considerations">
<t>
TODO: register link relation types, as necessary.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
This protocol MUST use <xref target="RFC2818">HTTP over TLS</xref>; this includes any
communications between device and push server, plus communications between the application
and the push server. This provides confidentiality and integrity protection for
registrations and push message.
</t>
<section title="Confidentiality from Push Server Access">
<t>
The protection afforded by TLS does not protect content from the push server. A push
server is able to see and modify the content of the messages.
</t>
<t>
Applications are able to provide additional confidentiality, integrity or authentication
mechanisms within the push message itself. The originating application server and the
device are frequently just different instances of the same application, this does not
require standardization. The process of registering a channel endpoints provides a
convenient medium for key agreement.
</t>
<t>
In particular, the W3C Web Push API requires that each push channel created by the browser
be bound to a browser generated encryption key. Pushed messages are authenticated and
decrypted by the browser before delivery. This ensures that the push server is unable to
examine the contents of push messages.
</t>
<t>
The public key for a channel ensures that applications using a channel can identify
messages from unknown sources and discard them. This depends on the public key only being
disclosed to entities that are authorized to send messages on the channel. The
push server does not require access to this public key.
</t>
</section>
<section title="Privacy Considerations">
<t>
Push message confidentiality does not ensure that the identity of who is communicating and
when they are communicating is protected. However, the amount of information that is
exposed can be limited.
</t>
<t>
The identifiers used by this protocol provide some ability to correlate communications for
a given device, either across applications or over time. Most important is that
communications for a given device not be able to be correlated between different
application usages, or between different times.
</t>
<t>
Channel URIs established by the same device MUST NOT include any information that allows
them to be correlated with other channels or the device registration. The push server is
the only entity that needs to be able to correlate channel URIs with device registrations.
Note that this can't prevent the use of traffic analysis in performing correlation.
</t>
<t>
A device MUST be able to create new registrations at any time. Identifiers for new
registrations MUST NOT include any information that allows them to be correlated with other
registrations from the same device or user.
</t>
</section>
<section title="Denial of Service Vectors">
<t>
This protocol does not specify a single authorization framework for managing access to push
servers, either by devices or applications. Thus, there is a very real possibility that
this could be exploited to mount denial of service attacks on the push server. Push
servers MAY choose to authorize requests based on any HTTP-compatible means available, of
which there are numerous options.
</t>
<t>
Discarding unwanted messages at the device based on message authentication doesn't protect
against a denial of service attack on the device. Even a relatively small number of
message can cause devices to exhaust batteries. Limiting the number of entities with
access to push channels limits the number of entities that can generate value push requests
of the push server. An application can do this by controlling the distribution of channel
URIs to authorized entities.
</t>
<t>
Only the push server can make this denial of service protection possible. A push server
MUST generate channel URI that are extremely difficult to guess. Encoding a large amount
of random entropy (at least 128 bits) in the URI path is one technique for ensuring that
channel URIs are able to act as bearer tokens.
</t>
<t>
A malicious application can use the greater resources of a push server to mount a denial of
service attack on devices. Push servers SHOULD limit the rate at which push messages are
sent to devices. <cref>...this suggests a mechanism whereby the server can inform devices
when it terminates channels or entire registrations.</cref>
</t>
<t>
Conversely, a push server is also able to deny service to devices. Intentional failure to
deliver messages is difficult to distinguish from faults, which might occur due to
transient network errors, interruptions in device availability, or genuine service
outages. Applications that rely on reliable message delivery need to provide means of
recovering from occasional failures that do not rely on push notifications.
</t>
</section>
<section title="Logging Exposure">
<t>
Server request logs can reveal registration and channel URIs. Acquiring a registration URI
permits the creation of new channels and the receipt of messages. Acquiring either URI
permits the generation of push messages. Logging could also reveal relationships between
different channel URIs for the same registration, or between different registrations for
the same device.
</t>
<t>
End-to-end confidentiality mechanisms, such as those in <xref target="API"/>, prevent an
entity with a registration URI from learning the contents of push messages. In both cases,
push messages that are not successfully authenticated will not be delivered by the API, but
this can present a denial of service risk. Limitations on log retention and strong access
control mechanisms can ensure that these URIs are not learned.
</t>
</section>
</section>
<!--
<section anchor="ack" title="Acknowledgements">
<t>
</t>
</section>
-->
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7231.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7235.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7240.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-http2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-alt-svc.xml"?>
</references>
<references title="Informative References">
<reference anchor="API" target="https://w3c.github.io/push-api/index.html">
<front>
<title>Web Push API</title>
<author initials="B." surname="Sullivan" fullname="Bryan Sullivan"/>
<author initials="E." surname="Fullea" fullname="Eduardo Fullea"/>
<date month="May" year="2014" />
</front>
<seriesInfo name="Editor's Draft" value="push-api" />
</reference>
</references>
<!--
<section title="Change Log">
<t>[[The RFC Editor is requested to remove this section at publication.]]</t>
<t>Changes since -0-1:
<list style="symbols">
<t>Document created.</t>
</list>
</t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:20:32 |