4. Subscribing for Push Messages
4. Subscribing for Push Messages
Der User Agent sendet POST an die konfigurierte Push-Service-Ressource, um ein neues Abonnement zu erstellen.
POST /subscribe HTTP/1.1
Host: push.example.net
201 (Created) bedeutet erfolgreiche Erstellung. Die URI der Abonnement-Ressource MUST im Feld Location zurückgegeben werden.
Der Push-Dienst MUST die URI der push resource in einer Link-Relation vom Typ urn:ietf:params:push bereitstellen.
Die Verteilung der Push-URI an den Anwendungsserver ist anwendungsspezifisch. Vertraulichkeit und Authentifizierung des Anwendungsservers MUST sicherstellen, dass die URI nicht an Unbefugte gelangt (Abschnitt 8.3).
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV>;
rel="urn:ietf:params:push"
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
Location: https://push.example.net/subscription/LBhhw0OohO-Wl4Oi971UG
4.1. Collecting Subscriptions into Sets
Mehrere Abonnements in einer subscription set zusammenzufassen kann Effizienz deutlich verbessern. Der Dienst MAY eine URI für die Menge in urn:ietf:params:push:set liefern.
Wird eine Menge in der Antwort zurückgegeben, SHOULD der User Agent diese Relation bei weiteren POST-Anfragen zum Erstellen von Abonnements mitsenden.
Der User Agent MAY die Menge weglassen, wenn er während der Lebensdauer nicht aggregiert empfangen kann (z. B. wenn er für andere Empfänger überwacht).
POST /subscribe HTTP/1.1
Host: push.example.net
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
Der Dienst SHOULD dieselbe Menge zurückgeben, MAY aber eine neue liefern, wenn die vom User Agent gelieferte nicht wiederverwendbar ist.
HTTP/1.1 201 Created
Date: Thu, 11 Dec 2014 23:56:52 GMT
Link: </push/YBJNBIMwwA_Ag8EtD47J4A>;
rel="urn:ietf:params:push"
Link: </subscription-set/4UXwi2Rd7jGS7gp5cuutF8ZldnEuvbOy>;
rel="urn:ietf:params:push:set"
Location: https://push.example.net/subscription/i-nQ3A9Zm4kgSWg8_ZijV
Bei ungültiger Menge MUST der Dienst 400 (Bad Request) antworten. Er MAY 429 (Too Many Requests) [RFC6585] senden, wenn die Menge fehlt.
Die Erkennung gleicher User Agents ist implementierungsspezifisch (TLS, Quell-IP, Port). Heuristiken können falsch positive Ablehnungen verursachen.