Generic Event Delivery Using HTTP Push
Extracted elements (30)
Consolidating all real-time events into a single push service session reduces unnecessary radio usage on mobile devices; uncoordinated use of persistent connections from multiple apps incurs duplicated keep-alive overhead that dominates over the infrequent actual events.
Subscription resources are modeled as two separate resources (a private subscription resource for the user agent and a public push resource for the application server) to offer more granular authorization control over who can send versus who can receive messages.
The alternate port 1001 is advertised via HTTP alternative services to allow middleboxes to optimize idle timeouts for push connections. The default port 443 has lower idle timeouts suited for web browsing, causing unnecessary radio communications on battery-powered devices.
When receiving push messages for a subscription set, the PUSH_PROMISE synthetic request MUST provide a URI for the push resource in a 'urn:ietf:params:push' link relation so the user agent can differentiate the source subscription for each delivered message.
A 201 (Created) response to a subscription POST request MUST return a URI for the push message subscription resource in the Location header field. The push service MUST also provide a URI for the push resource in a link relation of type 'urn:ietf:params:push'.
A DELETE request to a subscription set URI MUST also remove all push message subscriptions in the set. If a specific push message subscription in a set is expired or removed, it MUST also be removed from its subscription set.
A push service MAY retain a push message for a shorter duration than requested, indicated by returning a TTL header field in its response with the actual TTL, which MUST be less than or equal to the value provided by the application server. Once the TTL period elapses, the push service MUST NOT attempt delivery.
A push service MUST return a 404 (Not Found) status code if an application server attempts to send a push message to an expired push message subscription. Expiry of a subscription set MUST also expire all push message subscriptions in the set.
A user agent MUST support the 307 (Temporary Redirect) status code, which can be used by a push service to redistribute load at the time a new subscription is requested.
An application server MUST include the TTL (Time-To-Live) header field in its request for push message delivery. A push service MUST return a 400 (Bad Request) status code in response to requests that omit the TTL header field.
Confidentiality protection and application server authentication MUST be used to ensure the push URI is not disclosed to unauthorized recipients when distributing it from user agent to application server.
If a subscription set is available, the user agent SHOULD use the subscription set to monitor for push messages rather than individual push message subscription resources.
If the push service ceases to retry delivery prior to the message's advertised expiration and a delivery receipt was requested, the push service MUST return a 410 (Gone) response to the application server monitoring the receipt subscription.
Push services MUST NOT return a 413 (Payload Too Large) status code in response to an entity body that is 4096 bytes or less in size. A push service MAY return 413 for larger bodies.
The push service MUST NOT forward the Urgency header field to the user agent. The push service MUST NOT deliver push messages with lower urgency than the value indicated by the user agent in its monitoring request.
The push service MUST use HTTP over TLS (RFC 2818) following the recommendations in RFC 7525. This applies to all communications between the user agent and the push service, and between the application server and the push service.
The value of the Topic header field MUST NOT be forwarded to user agents; its value is neither encrypted nor authenticated.
To acknowledge receipt of a push message, the user agent MUST perform an HTTP DELETE on the push message resource. The push service MUST support delivery confirmations when the application server requests them via the Prefer: respond-async header.
When a user agent requests immediate delivery using Prefer: wait=0, the push service MUST generate a server push for all push messages that have not yet been delivered. A 204 (No Content) with no server pushes indicates no messages are currently available.
Push resource URIs MUST NOT provide any basis to correlate communications for a given user agent, and it MUST NOT be possible to correlate any two push resource URIs based solely on their contents. User and device information MUST NOT be exposed through a push or push message URI.
The Topic header field carries a string used to replace outstanding push messages with the same topic on the same subscription. Its value MUST be restricted to no more than 32 characters from the URL and filename-safe Base64 alphabet (RFC 4648).
The TTL header field contains a non-negative integer representing time in seconds. A recipient parsing TTL SHOULD use an arithmetic type of at least 31 bits; if the value exceeds the maximum representable integer, it MUST be treated as 2147483648 (2^31).
The Urgency header field accepts one of four values: 'very-low', 'low', 'normal', or 'high', indicating message urgency. A push message without the Urgency header field defaults to 'normal'. Multiple Urgency values MUST NOT be included in a single request.
A new 'Web Push Identifiers' registry is created under the URN prefix 'urn:ietf:params:push', operating under IETF Review policy. Initial entries define three link relation URNs: 'urn:ietf:params:push' (push resource), 'urn:ietf:params:push:set' (subscription set), and 'urn:ietf:params:push:receipt' (receipt subscription).
IANA has assigned TCP System Port number 1001 and service name 'webpush' for HTTP Web Push in the Service Name and Transport Protocol Port Number Registry.
Three new HTTP header fields are registered in the 'Permanent Message Header Field Names' registry: TTL (Section 5.2), Urgency (Section 5.3), and Topic (Section 5.4).
A push service SHOULD limit the rate at which push messages are sent to individual user agents to mitigate denial-of-service attacks. A push service MAY return 429 (Too Many Requests) with a Retry-After header when rate limits are exceeded.
Applications using this protocol MUST use mechanisms that provide end-to-end confidentiality, integrity, and data origin authentication because TLS only protects content from external parties, not from the push service itself.
Authorization is managed using capability URLs for push resources, acting as bearer tokens. Capability URLs MUST encode at least 120 bits of random entropy in the path component to prevent guessing attacks.
Server request logs can reveal subscription-related URIs or relationships between URIs for the same user agent. Limitations on log retention and strong access control mechanisms are recommended to prevent unauthorized disclosure.