[1] クライアントが保持できる Cookie は無限ではなく、制限を超えた Cookie は削除して構わないことになっています。
[21] 利用者エージェントは、同じドメインのクッキーが実装定義の上限を超えているなら、いつでも超過クッキーを削除して構いません >>20。 一般用の利用者エージェントは、ドメイン毎に最低50個のクッキーを扱えるべきです >>28。
[22] 利用者エージェントは、クッキーが予め決めた上限を超えているなら、いつでも超過クッキーを削除して構いません >>20。 一般用の利用者エージェントは、最低3000個のクッキーを扱えるべきです >>28。
[29] 一般用の利用者エージェントは、クッキー毎に最低4096バイト (名前、値、属性の総和) は扱えるべきです >>28。
[23] 超過クッキーを削除する場合は、
次の優先順位で削除しなければなりません >>20。
[27] 同位のクッキーの場合は、最終アクセス日付が早いものから順に削除しなければなりません >>20。
[30] 鯖は、利用者エージェント側の保管上限に達するのを避けるとともにネットワーク帯域を削減するため、 クッキーを極力少数に抑えるべきです >>28。
[3] NetscapeのCookie仕様は利用者エージェントが最低限保持するべきである量を定めています >>2。
[4] 鯖は、これ以上の Cookie を扱えると期待するべきではありません。 >>2
[11] RFC 2109, RFC 2965 では新しい Cookie のために古い Cookie を削除して構わないとされていましたが、その具体的な方法は LRU を例示しているものの特に規定していませんでした。 >>9, >>10
[12] また、利用者が削除する方法も用意するべきであるとされていました >>9, >>10。
逆に Max-Age や Discard
の指示よりも延命させてはならない >>10 とも RFC 2965 ではされていました。
[13] 古いからといって不要とは一概には言えないので、利用者がこの Cookie は永く保存する、この Cookie はすぐに廃棄する、といった選択を行えるのが良いだろう、 ともされていました >>9, >>10。
[15] サイズ制限はおおむね Netscape Cookie の規定 (>>3) と同じ値が採用されており (細部は異なることがあります)、その値を最低限扱えるべきである >>14, >>16 とされていました。ただし、長さ制限を超過した場合に、長さにあわせてぶった切ってはならず、 超過した Cookie 全体を破棄しなければならないとされていました >>14, >>16。
[19] 逆に大量の Cookie の発行による DoS 攻撃の防御のために上限を設けることも提案されていました >>17, >>18。