WEBPUSH M. Thomson Internet-Draft Mozilla Intended status: Standards Track May 12, 2014 Expires: November 13, 2014 Generic Event Delivery Using HTTP Push draft-thomson-webpush-http2-00 Abstract A simple scheme for the delivery of realtime events to clients is described. This scheme uses HTTP/2 push. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 13, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Thomson Expires November 13, 2014 [Page 1] Internet-Draft HTTP Push May 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Delivering Push Messages . . . . . . . . . . . . . . . . . . 5 4. Registering . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Monitoring and Receiving Push Messages . . . . . . . . . . . 6 7. Store and Forward Operation . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 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. One significant contributor to power usage mobile devices is the radio. Cellular - and to a lesser extent, IEEE 802 radios - consume a significant portion of the energy budget on a wirelessly connected mobile device. 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. 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. Thomson Expires November 13, 2014 [Page 2] Internet-Draft HTTP Push May 2014 The Web Push API [API] 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: o request the delivery of an event to an attached device o register a new device, create new event delivery channels, and monitor those channels for new events 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 advantages that standardization affords. 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. 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. Similarly, discovery of support for and negotiation of use of alternative monitoring schemes is left to documents that extend this basic protocol. 1.1. Conventions and Terminology 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 [RFC2119]. This document will use the terminology from [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. Thomson Expires November 13, 2014 [Page 3] Internet-Draft HTTP Push May 2014 2. Overview A general model for push services includes three basic actors: a device, a push server, and an application. +-----------+ +-------------+ +-------------+ | Device | | Push Server | | Application | +-----------+ +-------------+ +-------------+ | | | | Register | | |--------------------->| | | Monitor | | |<====================>| | | Get Channel | | |--------------------->| | | Provide Channel | |-------------------------------------------->| | | Push Message | | Push Message |<---------------------| |<---------------------| | | | | 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. 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). 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. Applications use channels to deliver push messages to devices, via the push server. Both registrations and channels have a limited lifetime. These will need to be refreshed over time. Thomson Expires November 13, 2014 [Page 4] Internet-Draft HTTP Push May 2014 3. Delivering Push Messages A push channel is identified with an HTTP URI [I-D.ietf-httpbis-p1-messaging]. 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. 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 Section 7) could respond with a 202 (Accepted) status code to indicate that the message was stored, but not delivered. 4. Registering 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. 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 link relations that are included in Link header fields in the response. monitor: A link relation of type "...:push:monitor" includes the URL of a resource that the device can monitor for events. Monitoring is described in Section 6. 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 Section 5. The push server includes the "monitor" link relation in a Location header field. 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 [I-D.ietf-httpbis-p6-cache]. The push server SHOULD also provide the "channel" link and expiration information in response to requests to the "monitor" resource. Thomson Expires November 13, 2014 [Page 5] Internet-Draft HTTP Push May 2014 5. Channels A client sends a POST request to the "channel" resource to create a new channel. A response with a 201 status code includes the channel URI in the Location header field. 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. A client can explicitly delete a channel by sending a DELETE request to channel URI. 6. Monitoring and Receiving Push Messages 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 server push [I-D.ietf-httpbis-http2] to send the contents of push messages as applications send them. 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. A device can request the monitor resource immediately by including a Prefer header field [I-D.snell-http-prefer] with a "wait" parmeter set to "0". A server that wishes to redistribute load can do so using The alternative services mechanisms that are part of HTTP/2 [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. 7. Store and Forward Operation 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. Push servers are permitted to store messages for some time to allow for limited recovery from transient faults. If a message is stored, Thomson Expires November 13, 2014 [Page 6] Internet-Draft HTTP Push May 2014 but not delivered, the push server can indicate the probable duration of storage by including expiration information in the response to the push request. 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. 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. 8. IANA Considerations TODO: register link relation types, as necessary. 9. Security Considerations This protocol does not specific 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 service. Push services MAY choose to authorize requests based on any HTTP- compatible means available, of which there are numerous options. A malicious application can use the greater resources of a push server to mount a denial of service attack on devices. Push servers MAY limit the rate at which push messages are sent to devices. One basic protection against misuse of push channels is to ensure that only authorized applications are given channel URIs and to make it extremely difficult to successfully guess a valid channel URI. Encoding a large amount of random entropy in the URI path is one technique for ensuring that channel URIs are able to act as bearer tokens. A push server is able to see (and modify) the content of push messages. Applications that depend on end-to-end guarantees MUST use object security mechanisms to protect the confidentiality and integrity of push messages. Since the application frequently resides both in the server that originates the push messages and in the device, and there is a requirement for direct communications between Thomson Expires November 13, 2014 [Page 7] Internet-Draft HTTP Push May 2014 these two instances to exchange channel information, this provides a perfect medium for key agreement. A push server is also able to deny service. In addition to malicious reasons, delivery of push messages can fail due to transient faults in networks, the device being temporarily unavailable, or other similar faults. Therefore, applications that rely on the content of push messages being delivered MUST ensure that they provide other means of delivering messages to devices. 10. References 10.1. Normative References [I-D.ietf-httpbis-alt-svc] mnot, m., McManus, P., and J. Reschke, "HTTP Alternative Services", draft-ietf-httpbis-alt-svc-01 (work in progress), April 2014. [I-D.ietf-httpbis-http2] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Protocol version 2", draft-ietf-httpbis-http2-12 (work in progress), April 2014. [I-D.ietf-httpbis-p1-messaging] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", draft-ietf- httpbis-p1-messaging-26 (work in progress), February 2014. [I-D.ietf-httpbis-p6-cache] Fielding, R., mnot, m., and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Caching", draft-ietf- httpbis-p6-cache-26 (work in progress), February 2014. [I-D.snell-http-prefer] Snell, J., "Prefer Header for HTTP", draft-snell-http- prefer-18 (work in progress), January 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [API] Sullivan, B. and E. Fullea, "Web Push API", Editor's Draft push-api, May 2014, . Thomson Expires November 13, 2014 [Page 8] Internet-Draft HTTP Push May 2014 Author's Address Martin Thomson Mozilla 331 E Evelyn Street Mountain View, CA 94041 US Email: martin.thomson@gmail.com Thomson Expires November 13, 2014 [Page 9]