5. Requesting Push Message Delivery

Le serveur d'application demande la livraison d'un message poussé en envoyant une requête HTTP POST vers la ressource push fournie par le user agent. Le corps de la requête contient le message.

POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 15
Content-Type: text/plain;charset=utf8
Content-Length: 36

iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB

201 (Created) indique que le message a été accepté. L'URI de la ressource créée MUST figurer dans Location. Cela n'indique pas que le message a été livré au user agent.

HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:55 GMT
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt

5.1. Requesting Push Message Receipts

Le serveur d'application peut inclure le champ Prefer [RFC7240] avec la préférence respond-async pour demander une confirmation lorsque le message est livré puis accusé par le user agent. Le service push MUST prendre en charge les confirmations.

POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
Prefer: respond-async
TTL: 15
Content-Type: text/plain;charset=utf8
Content-Length: 36

iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB

Lorsque le service accepte le message avec confirmation, il MUST renvoyer 202 (Accepted). L'URI de la ressource message MUST être dans Location. Il MUST aussi fournir l'URI de l'abonnement aux accusés dans une relation urn:ietf:params:push:receipt.

HTTP/1.1 202 Accepted
Date: Thu, 11 Dec 2014 23:56:55 GMT
Link: </receipt-subscription/3ZtI4YVNBnUUZhuoChl6omUvG4ZM>;
        rel="urn:ietf:params:push:receipt"
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt

Pour les requêtes ultérieures vers la même origine [RFC6454], le serveur d'application SHOULD inclure l'abonnement aux accusés retourné. Le service SHOULD renvoyer le même abonnement, mais MAY en renvoyer un nouveau s'il ne peut pas réutiliser celui fourni.

Le serveur d'application MAY omettre l'abonnement s'il ne peut pas recevoir les accusés de façon agrégée pendant toute la durée de vie.

Le service MUST renvoyer 400 pour un abonnement aux accusés invalide. Il MAY renvoyer 429 [RFC6585] s'il limite le nombre d'abonnements et que la requête omet l'abonnement.

5.2. Push Message Time-To-Live

Stocker temporairement les messages améliore la fiabilité. Les user agents sont souvent intermittents et bénéficient d'un stockage court côté service.

Retarder la livraison peut aussi permettre de regrouper les communications et d'économiser la radio.

Certains messages ne sont plus utiles après un délai ; les livrer ensuite est inutile (ex. notification d'appel après raccrochage).

Le serveur d'application MUST inclure le champ TTL. Il indique en secondes combien de temps le service peut conserver le message.

La règle TTL est un entier non négatif (secondes). Le destinataire SHOULD utiliser un type d'au moins 31 bits non signés. S'il reçoit une valeur trop grande ou si un calcul déborde, il MUST traiter la valeur comme 2147483648 (2^31).

TTL = 1*DIGIT

Le service MUST renvoyer 400 si TTL est absent.

Le service MAY conserver le message moins longtemps ; il indique le TTL réel dans la réponse. Ce TTL MUST être inférieur ou égal à la valeur demandée.

Après expiration, le service MUST NOT tenter de livrer. Le service peut ajuster le TTL pour tenir compte des erreurs de temps (horloge, propagation).

Le service n'est pas tenu de compter le temps côté serveur d'application ou les délais vers le user agent. Le serveur d'application doit tenir compte des délais de transit.

Un message avec TTL zéro est livré immédiatement si le user agent est disponible. Après livraison, le service peut supprimer le message avant DELETE du user agent ; les accusés pour TTL 0 ne sont donc pas fiables. Si le user agent est absent, le message expire sans être livré.

5.3. Push Message Urgency

Sur batterie, rester inactif longtemps est crucial ; la radio consomme beaucoup.

Il est utile que le serveur d'application puisse indiquer l'urgence et que le user agent ne demande que certains niveaux.

Le serveur d'application MAY inclure Urgency. Le service push MUST NOT transmettre ce champ au user agent. Sans Urgency, la valeur par défaut est normal.

Le user agent MAY inclure Urgency lors de la surveillance pour indiquer le niveau minimal qu'il accepte. Le service MUST NOT livrer des messages d'urgence inférieure. Sans Urgency du user agent, tous les niveaux sont livrés.

Urgency = urgency-option
urgency-option = ("very-low" / "low" / "normal" / "high")

Par ordre d'urgence croissante :

Urgency	Device State	Example Application Scenario
very-low	On power and Wi-Fi	Advertisements
low	On either power or Wi-Fi	Topic updates
normal	On neither power nor Wi-Fi	Chat or Calendar Message
high	Low battery	Incoming phone call or time-sensitive alert

Tableau 1 : valeurs d'urgence illustratives

Plusieurs valeurs Urgency MUST NOT figurer dans une requête ; sinon le service MUST renvoyer 400.

5.4. Replacing Push Messages

Un message stocké peut être remplacé. Si le user agent est hors ligne, cela évite d'envoyer des messages obsolètes.

Seuls les messages ayant un topic peuvent être remplacés. Un message avec topic remplace tout message en attente avec le même topic.

Le topic est une chaîne dans le champ Topic ; il corrèle les messages vers le même abonnement sans autre sémantique.

Topic = token

([RFC7230], règle token.)

Topic MUST être limité à 32 caractères au plus de l'alphabet Base 64 sûr pour URL et noms de fichiers [RFC4648]. Sinon le service MUST renvoyer 400.

La requête de remplacement crée une nouvelle ressource message et supprime toute ressource existante avec le même topic. Un accusé pour l'ancien message peut arriver après remplacement ; ces accusés SHOULD être supprimés.

Le remplacement met aussi à jour le TTL, l'urgence et l'abonnement aux accusés associés au message précédent pour ce topic.

Un message avec un topic sans autre message en attente sur le même abonnement est traité normalement.

Exemple :

POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 600
Topic: upd
Content-Type: text/plain;charset=utf8
Content-Length: 36

ZuHSZPKa2b1jtOKLGpWrcrn8cNqt0iVQyroF

Si un message en attente a le topic upd, il est supprimé. 201 indique que le remplacement est accepté ; Location contient la nouvelle ressource.

HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:57:02 GMT
Location: https://push.example.net/message/qDIYHNcfAIPP_5ITvURr-d6BGt

La valeur Topic MUST NOT être transmise aux user agents. Elle n'est ni chiffrée ni authentifiée.