[17]
TTL:
は、
プッシュメッセージの保持期間を示す
HTTPヘッダーです。
仕様書
- [1] RFC 8030 - Generic Event Delivery Using HTTP Push, https://tools.ietf.org/html/rfc8030#section-5.2
意味
[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.
- +
- ASCII数字
[18] デルタ秒と実質同じで、規定もほぼ同じですが、
なぜか独自の規定になっています。処理
[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.