[17]
TTL:
は、
プッシュメッセージの保持期間を示す
HTTPヘッダーです。
[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] 受信者は、扱える値より大きな値が指定されたときや、 以後の計算で桁溢れするなら、 231 とみなさなければなりません。 >>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.