Passa al contenuto principale

5. Requesting Push Message Delivery

5. Requesting Push Message Delivery​

Il server applicativo richiede la consegna con HTTP POST sulla push resource distribuita dall'user agent. Il contenuto del messaggio è nel corpo della richiesta.

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) indica accettazione. L'URI della risorsa push message creata MUST essere in Location. Ciò non indica che il messaggio sia stato consegnato all'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​

Il server applicativo può includere Prefer [RFC7240] con respond-async per richiedere conferma dopo consegna e acknowledgment dell'user agent. Il push service MUST supportare le conferme di consegna.

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

Con accettazione e conferma, il servizio MUST restituire 202 (Accepted). Location contiene l'URI del messaggio. Il servizio MUST inoltre fornire l'URI della receipt subscription in 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

Per successive richieste di ricevuta verso la stessa origin [RFC6454], il server applicativo SHOULD includere la receipt subscription restituita. Il servizio SHOULD restituire la stessa subscription, ma MAY restituirne una nuova se non può riusare quella fornita.

Il server applicativo MAY omettere la subscription se non può ricevere ricevute in modo aggregato.

Con receipt subscription non valida, il servizio MUST rispondere 400. Per limitare il numero, MAY inviare 429 [RFC6585] se la subscription è omessa.

5.2. Push Message Time-To-Live​

La memorizzazione temporanea migliora l'affidabilità. Gli user agent sono spesso connessi solo a intervalli.

Ritardare la consegna può raggruppare il traffico verso l'user agent e risparmiare la radio.

Alcuni messaggi non sono utili dopo un certo tempo; consegnarli in ritardo spreca risorse (es. notifica di chiamata dopo l'abbandono).

Il server applicativo MUST includere TTL (secondi, durata desiderata di conservazione).

TTL è un intero non negativo. Il destinatario SHOULD usare almeno 31 bit. In caso di overflow o valore troppo grande, MUST trattare il valore come 2147483648 (2^31).

TTL = 1*DIGIT

Senza TTL, il servizio MUST rispondere 400.

Il servizio MAY conservare per meno tempo e indicare il TTL effettivo nella risposta; tale valore MUST essere minore o uguale a quello richiesto.

Dopo la scadenza, il servizio MUST NOT tentare la consegna. Il servizio può correggere il TTL per errori di misura del tempo (cluster, skew, ritardi).

Il servizio non è obbligato a conteggiare il tempo lato server applicativo o i ritardi verso l'user agent. Il server applicativo deve considerare i ritardi di transito nella scelta del TTL.

TTL 0: consegna immediata se l'user agent è disponibile; poi cancellazione immediata possibile prima del DELETE; le ricevute per TTL 0 non sono affidabili. Se l'user agent non è disponibile, il messaggio scade.

5.3. Push Message Urgency​

Sui dispositivi a batteria è importante restare inattivi a lungo; la radio consuma molta energia.

Il server applicativo MAY impostare Urgency. Il push service MUST NOT inoltrare questo campo all'user agent. Senza Urgency il default è normal.

L'user agent MAY includere Urgency in monitoraggio (urgenza minima accettata). Il servizio MUST NOT consegnare messaggi meno urgenti. Senza Urgency dall'user agent, tutti i livelli sono consegnati.

Urgency = urgency-option
urgency-option = ("very-low" / "low" / "normal" / "high")
UrgencyDevice StateExample Application Scenario
very-lowOn power and Wi-FiAdvertisements
lowOn either power or Wi-FiTopic updates
normalOn neither power nor Wi-FiChat or Calendar Message
highLow batteryIncoming phone call or time-sensitive alert

Più valori Urgency MUST NOT nella stessa richiesta; altrimenti MUST 400.

5.4. Replacing Push Messages​

I messaggi memorizzati possono essere sostituiti. Solo i messaggi con topic sono sostituibili; stesso topic sostituisce messaggi in sospeso con topic identico.

Il topic è nel campo Topic; correla solo messaggi verso lo stesso abbonamento.

Topic = token

Topic MUST essere al massimo 32 caratteri dall'alfabeto Base 64 sicuro per URL e nomi file [RFC4648]; altrimenti MUST 400.

Una richiesta di sostituzione crea una nuova risorsa push message e elimina risorse esistenti con topic corrispondente. Se si tentava di consegnare il messaggio eliminato, un acknowledgment può arrivare dopo la sostituzione. Le ricevute di consegna per tali messaggi eliminati SHOULD essere soppresse.

La sostituzione aggiorna anche TTL, Urgency e eventuale receipt subscription del messaggio precedente per quel topic.

Un messaggio con topic non condiviso da messaggi in sospeso sullo stesso abbonamento viene memorizzato o consegnato normalmente.

Il messaggio seguente potrebbe ad esempio sostituirne uno esistente:

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

ZuHSZPKa2b1jtOKLGpWrcrn8cNqt0iVQyroF

Se il push service identifica un push message in sospeso con topic upd, quella risorsa viene eliminata. 201 (Created) indica accettazione della sostituzione. Location contiene l'URI della nuova risorsa.

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

Il valore del campo Topic MUST NOT essere inoltrato agli user agent. Non è né cifrato né autenticato.

Ultimo aggiornamento il