メインコンテンツまでスキップ

5. プッシュメッセージ配信の要求

5. プッシュメッセージ配信の要求​

アプリケーションサーバ (application server) は, ユーザエージェントが配布したプッシュリソースへ HTTP POST リクエストを送ることでプッシュメッセージの配信を要求する. プッシュメッセージの内容はリクエストボディに含まれる.

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) レスポンスはプッシュメッセージが受理されたことを示す. リクエストに応じて作成されたプッシュメッセージリソースの URI は Location ヘッダフィールドに返さなければならない (MUST). これはメッセージがユーザエージェント (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 (プッシュメッセージ受領確認の要求)​

アプリケーションサーバは Prefer ヘッダフィールド [RFC7240] に respond-async 選好を含め, プッシュメッセージが配信されユーザエージェントによって確認されたときにプッシュサービスからの確認を要求できる. プッシュサービスは配信確認をサポートしなければならない (MUST).

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

プッシュサービスが確認付き配信のためにメッセージを受理するとき, 202 (Accepted) レスポンスを返さなければならない (MUST). リクエストに応じて作成されたプッシュメッセージリソースの URI は Location ヘッダフィールドに返さなければならない (MUST). プッシュサービスはまた型 urn:ietf:params:push:receipt のリンク関係で受領購読リソースの URI を提供しなければならない (MUST).

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

同一オリジン [RFC6454] への後続の受領リクエストでは, アプリケーションサーバは返された受領購読を型 urn:ietf:params:push:receipt のリンク関係に含めるべきである (SHOULD). これによりプッシュサービスは受領を集約する選択肢を持つ. プッシュサービスはレスポンスで同じ受領購読を返すべきである (SHOULD) が, アプリケーションサーバが提供したものを再利用できない場合は新しい受領購読を返してもよい (MAY).

受領購読の生存期間中に集約方式で受領を受け取れない場合, アプリケーションサーバは受領購読を省略してもよい (MAY). アプリケーションサーバが他のプッシュメッセージ送信者に代わって受領購読を監視する場合に必要となりうる.

プッシュサービスは無効な受領購読を含むリクエストに対して 400 (Bad Request) ステータスコードを返さなければならない (MUST). プッシュサービスが維持する受領購読数を制限したい場合, 受領購読を省略した受領リクエストを拒否するために 429 (Too Many Requests) ステータスコード [RFC6585] を返してもよい (MAY).

5.2. Push Message Time-To-Live (プッシュメッセージ TTL)​

プッシュサービスはプッシュメッセージを一定期間保存することで配信の信頼性を大きく改善できる. ユーザエージェントはしばしば断続的に接続するため, プッシュサービス側の短期メッセージ保存の恩恵を受ける.

配信の遅延はユーザエージェントとの通信をバッチ化し無線リソースを節約するためにも用いられうる.

一部のプッシュメッセージは一定時間が経過すると有用でなくなる. 関連性を失った後の配信は浪費である. 例えばプッシュメッセージが着信通知を含む場合, 発信者が呼を放棄した後にメッセージを受け取っても価値がない. ユーザエージェント上のアプリケーションは無意味なアラートを出さないようメッセージを抑制せざるを得ない.

アプリケーションサーバはプッシュメッセージ配信のリクエストに TTL (Time-To-Live) ヘッダフィールドを含めなければならない (MUST). TTL ヘッダフィールドは秒単位の値を含み, プッシュサービスがプッシュメッセージを保持する期間を示唆する.

TTL 規則は非負整数を指定し, 時間を秒で表す. 受信者が TTL 値を解析して二進形式に変換するとき, 少なくとも 31 ビットの非負整数範囲を持つ算術型を用いるべきである (SHOULD). 受信者が表現可能な最大整数より大きい TTL 値を受け取った場合, または後続の計算のいずれかがオーバーフローした場合, 値は 2147483648 (2^31) と見なさなければならない (MUST).

TTL = 1*DIGIT

プッシュサービスは TTL ヘッダフィールドを省略したリクエストに対して 400 (Bad Request) ステータスコードを返さなければならない (MUST).

プッシュサービスは要求より短い期間だけプッシュメッセージを保持してもよい (MAY). 実際の TTL を含む TTL ヘッダフィールドをレスポンスで返すことでこれを示す. この TTL 値はアプリケーションサーバが提供した値以下でなければならない (MUST).

TTL 期間が経過すると, プッシュサービスはプッシュメッセージをユーザエージェントへ配信しようとしてはならない (MUST NOT). プッシュサービスは処理における時間計上誤差を補うために TTL 値を調整しうる. 例えばサーバクラスタ内でプッシュメッセージを配布するとき, クロックスキューまたは伝播遅延により誤差が蓄積しうる.

プッシュサービスはアプリケーションサーバがプッシュメッセージをプッシュサービスへ送るのに費やした時間や, ユーザエージェントへ送る際の遅延を勘定に入れる義務はない. アプリケーションサーバは TTL ヘッダフィールド値の選択において経路遅延を勘定に入れる必要がある.

TTL がゼロのプッシュメッセージは, ユーザエージェントが受信可能であれば直ちに配信される. 配信後, プッシュサービスは TTL ゼロのプッシュメッセージを直ちに削除してよい. これはユーザエージェントがプッシュメッセージリソースに対して HTTP DELETE を実行して受領を確認する前に起こりうる. したがってアプリケーションサーバは TTL ゼロのプッシュメッセージについて受領確認の受領に依存してはならない.

ユーザエージェントが利用できない場合, TTL ゼロのプッシュメッセージは期限切れとなり決して配信されない.

5.3. Push Message Urgency (プッシュメッセージの緊急度)​

バッテリー駆動のデバイスでは, 長期間ドーパント状態を保つことがしばしば重要である. 特に無線通信は電力を大きく消費し, デバイスが動作できる時間を制限する.

些細なメッセージを受信するためにリソースを消費することを避けるため, アプリケーションサーバがメッセージの緊急度を伝え, ユーザエージェントがプッシュサーバに特定の緊急度のメッセージのみを転送するよう要求できると有用である.

アプリケーションサーバはプッシュメッセージ配信のリクエストに Urgency ヘッダフィールドを含めてもよい (MAY). このヘッダフィールドはメッセージの緊急度を示す. プッシュサービスは Urgency ヘッダフィールドをユーザエージェントへ転送してはならない (MUST NOT). Urgency ヘッダフィールドのないプッシュメッセージのデフォルトは normal である.

ユーザエージェントはプッシュメッセージの監視時に Urgency ヘッダフィールドを含めてもよい (MAY). これは受信を望む最低のプッシュメッセージ緊急度を示す. プッシュサービスは, ユーザエージェントの監視リクエストで示された値より低い緊急度のプッシュメッセージを配信してはならない (MUST NOT). メッセージ監視時に Urgency ヘッダフィールドを含めないユーザエージェントには任意の緊急度のプッシュメッセージが配信される.

Urgency ヘッダフィールドの文法は次のとおり:

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

表 1: 説明的な緊急度の値

リクエストに Urgency ヘッダフィールドの複数の値を含めてはならない (MUST NOT). さもなければプッシュサービスは 400 (Bad Request) ステータスコードを返さなければならない (MUST).

5.4. Replacing Push Messages (プッシュメッセージの置換)​

プッシュサービスによって保存されたプッシュメッセージは新しい内容で置換できる. プッシュメッセージ送信の間ユーザエージェントがオフラインである場合, プッシュメッセージを更新することで古いまたは冗長なメッセージがユーザエージェントに送られる状況を避けられる.

トピックが割り当てられたプッシュメッセージのみが置換可能である. トピックを持つプッシュメッセージは, 同一トピックの未処理プッシュメッセージを置換する.

プッシュメッセージトピックは Topic ヘッダフィールドに運ばれる文字列である. トピックは同一購読へ送られたプッシュメッセージを相関させるために用いられ, 他の意味は持たない.

Topic ヘッダフィールドの文法は [RFC7230] で定義される token 規則を用いる.

Topic = token

本プロトコルでの使用に際しては, Topic ヘッダフィールドは URL およびファイル名安全な Base 64 アルファベット [RFC4648] から 32 文字を超えないように制限されなければならない (MUST). これらの制約を満たさない Topic ヘッダフィールドを含むリクエストをプッシュサービスが受け取った場合, アプリケーションサーバに 400 (Bad Request) ステータスコードを返さなければならない (MUST).

プッシュメッセージ置換リクエストは新しいプッシュメッセージリソースを作成し, 同時に一致するトピックを持つ既存のメッセージリソースをすべて削除する. 削除されたプッシュメッセージの配信が試みられていた場合, プッシュメッセージが置換された後に確認がプッシュサービスに到着しうる. そのような削除されたメッセージの配信受領は抑制すべきである (SHOULD).

置換リクエストは, 一致するトピックの前メッセージに関連付けられていた保存済み TTL, Urgency, および任意の受領購読も置換する.

同一購読への未処理メッセージとトピックを共有しないプッシュメッセージは通常どおり保存または配信される.

例えば次のメッセージは既存メッセージの置換を引き起こしうる:

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

ZuHSZPKa2b1jtOKLGpWrcrn8cNqt0iVQyroF

プッシュサービスがトピック upd の未処理プッシュメッセージを識別した場合, そのメッセージリソースは削除される. 201 (Created) レスポンスはプッシュメッセージ置換が受理されたことを示す. リクエストに応じて作成された新しいプッシュメッセージリソースの URI が Location ヘッダフィールドに含まれる.

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

Topic ヘッダフィールドの値はユーザエージェントへ転送してはならない (MUST NOT). その値は暗号化も認証もされていない.

に最終更新