[2] HTTP の Cookie2: 要求頭欄は、
利用者エージェントが対応している Cookie 仕様の最高の版を示します。
[6] クライアントは、 Cookie: 欄を使って1つ以上の Cookie
を送る場合であって、その $Version がクライアントの理解する
Cookie の版と異なる場合にあっては、クライアントが理解する最高の Cookie
の版を Cookie2: 欄に含めなければなりません >>4。
Version の Cookie は廃棄しなければならないという規定は無いようなので、
「異なる」というのは 0 だったり 2 だったり、1 以外すべてですね。。。
仮に利用者エージェントが版 1 と版 4 を理解するとしたら、1 だけを送出するときは
Cookie2: を使う必要なない、と。 5 を送出するときは使う必要があるけど。[9] Cookie2: を使った Netscape Cookie から RFC 2965 への Cookie
へのアップグレードの方法は次の通りです。
[7] Cookie2: なんていう名前だから Cookie:
の代替かと思いきや、単に版番号を書くだけなんですね。。。
[1]
Cookie2 欄なんて対応している UA あるのかよ?と思っていましたけど、ほどほどの頻度で観測されていますね。どんな UA が実装しているのだろう。
(名無しさん 2004-04-02 01:27:23 +00:00)
[16] HTTP::Cookies - search.cpan.org ( ( 版)) http://search.cpan.org/dist/HTTP-Cookies/lib/HTTP/Cookies.pm
[17] 252342 – fix cookie domain checks to not allow .co.uk ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=252342
[19] Cookie2 とは何か | blog.jxck.io, Jxck, , https://blog.jxck.io/entries/2023-08-19/cookie2.html
[20]
>>19 著者は知ってて冗長になるのを嫌って省いたのかもしれませんけど、
RFC 6265 制定作業の出発点は HttpOnly の標準化の動きだった、
という点も抑えておきたかったですね。
当初は新機能だけ規定するつもりで始めたのに、
新機能を追加するべき土台がしっかりしていないとやっぱり駄目だと気づいてクッキー仕様を全部ちゃんと作ることにした、
という流れを。
Cookie2: $Version="1"」のようになっていて、 矛盾しています。