仕様書

意味

[4] TTL: ヘッダー値は、 プッシュサービスがプッシュメッセージを保持するべき秒数を指定します。 >>1 5.2.

[12] プッシュサービスは、 TTL 期間経過後、 プッシュメッセージを利用者エージェントに配送しようとしてはなりません。 >>1 5.2.

[13] プッシュサービスは、 アプリケーションサーバーからプッシュサービスへの送信や、 プッシュサービスから利用者エージェントへの送信にかかる時間を考慮する義務はありません。 アプリケーションサーバーは TTL: 値決定にこうした要素を考慮する必要があります。 >>1 5.2.

文脈

[2] プッシュメッセージは、 短期間しか有意義でないこともありますし、 保管や転送の資源節約のこともあり、 有効期限が設けられています。 >>1 5.2.

[3] Web Push アプリケーションサーバーは、 プッシュ資源への要求に TTL: ヘッダーを含めなければなりません。 >>1 5.2.

[10] プッシュサービスは、 要求されたより保持期間を短くする場合、 これを応答の TTL: ヘッダーで示さなければなりません。 この場合値は要求された値以下でなければなりません。 >>1 5.2.

構文

[5] ヘッダー値は、 1つ以上のASCII数字です。 >>1 5.2.

処理

[8] プッシュサービスは、 プッシュ資源への要求に TTL: ヘッダーがないとき、 400 応答を返さなければなりません。 >>1 5.2.

[6] ヘッダー値は、 秒単位の時間を非負整数で指定したものです。 受信者は、2進数で保持する場合、 最低31ビットの非負整数を扱える算術型を使うべきです。 >>1 5.2. 明記されていませんが、10進数で記述するもののようです。

[7] 受信者は、扱える値より大きな値が指定されたときや、 以後の計算で桁溢れするなら、 2³¹ とみなさなければなりません。 >>1 5.2.

[16] 不適切な値のときや、複数のHTTPヘッダーが指定された時どう処理するべきか不明です。 仕様書に規定がありまえん。

[9] プッシュサービスは、 プッシュメッセージの保持期間を指定よりも短くしても構いません。 >>1 5.2.

[11] プッシュサービスは、 処理中の誤差を鑑みて TTL 値を調整することができます。 例えばプッシュメッセージをサーバー群間で配布するときに、 clock skew や伝播遅延で誤りが蓄積するかもしれません。 >>1 5.2.

[14] 値 0 の場合、 利用者エージェントが受信できる状態なら即座に配送されます。 そうでない場合は配送されずに捨てられます。 >>1 5.2.

[15] 配送されてもプッシュサービスはすぐにプッシュメッセージを削除できるので、 利用者エージェントから受信肯定すら受け取れないかもしれず、 アプリケーションサーバーは肯定受領証を受信できる保証がありません。 >>1 5.2.

メモ