[1] Cookie では Expires
属性の値として日時が使われますが、
Wdy, DD-Mon-YYYY HH:MM:SS GMT
のような独自の書式で日時を記述します。
Wdy, DD-Mon-YYYY HH:MM:SS GMTのように日時を UTC で記述します。>>14 HTTPの日付形式に似ていますが、日の要素間に
-
を入れなければいけません。This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the variations that the only legal time zone is
GMT
and the separators between the elements of the date must be dashes.
などと訳がわからないことが書かれています。当時は HTTP が RFC 化されていなかったのでそれを参照していないのは仕方がないにせよ (でも Internet Draft はあったはず)、 なんでこんなおかしな説明の書き方をしたのかは謎です。
[17] 仕様書で示された書式や実際の例示 >>2 の書式は RFC 850の日付形式に一番近いですが、 >>16
にある通り時間帯が GMT
に固定されています。
Wdy とあるといかにも省略形の曜日が使われそうですが、
>>2 の例示は長い名前になっていて、これは RFC 850 と一致しています。
現実には短い名前の方が一般的な気がします。
[21] 利用者エージェントによって2桁西暦年号の解釈が異なるため、 4桁の年号を指定するRFC 1123の日付形式を使うべきである >>19 とされています。
[22] 利用者エージェントによっては 32ビットの time_t で日付を処理しますが、そのため実装によっては不具合により 2038年以降の日付を正しく処理できないことがある >>19 と指摘されています。
[34] 構文解析の方法に従うと、1600年とそれ以前は正しく処理されないことになります。 構文上はそのような制約は明記されていません。
[28] RFC 6265 は次のような構文解析の算法を規定しています >>24。これに従えば HTTPの日付形式と元々の Netscape の日付形式のいずれも解釈できます。
[31] 閏秒を記述しても良いかどうかについては、 RFC 2616 に定義が委ねられており、その RFC 2616 は明確に規定していないため、不明です。 (HTTPの日付形式を参照してください。)
[25] RFC 6265 は Cookieの日付形式、HTTPの日付形式を構文解析できる算法を定義しています。
ただし字句の定義が若干間違っています。 ( non-digit *OCTET )
は省略可能と解釈する必要があります。
[33] au の2011年秋以降の端末では Cookie の仕様変更がありました。
それに伴い、 HTTPの日付形式 (RFC 1123の日付形式) は受け付けなくなり、
元々の Netscape の規定に基づく「-」が入る形式でなければ
Expires
属性は無視されてしまうようになりました。
[26] <https://github.com/abarth/http-state/tree/master/tests/data/dates> に日付の構文解析のテスト・データがあります。
Fri, 24-Jan-2003 16:41:00 GMT
Wednesday, 09-Nov-99 23:12:40 GMT
;; >>6Mon, 30 Dec 2020 23:59:59 GMT
;; 不正: HTTP 形式Thursday, 31-Dec-2037 00:00:00 JST
;; 不正: 長い曜日名, 未定義の時間帯名[3] >>2 の例は Netscape の仕様書からの引用ですが、ここでは4桁でなければならないと規定されているはずの年号が2桁になっています。 (それに、 >>1 の構文なら曜日は短い名前のはずだと思うのですがね。)
[4] 巷の CGI script などを見ていると、日付の指定が間違っているものも見受けられます。
[8] >>4,>>6-7 当然、不正な形式に対する動作は未定義です。
とはいえ、 >>2 のように仕様からしてぐちゃぐちゃなので、どうしたものでしょうか。
[9] >>8 もちろん、 >>1 の形式を使えば全ての Cookie 対応 UA で問題なく処理されるはずです。
[10] >>8 そういうのを解説してる書籍とか Web page があるらしいです。ひどいな!
[11] [JavaHouse-Brewers:31373] Re: Cookie.setMaxAge() について ( 版) <http://java-house.jp/ml/archive/j-h-b/031373.html>
「問題」
ブラウザがInternet Explorer 5の場合、
- Cookie.setMaxAge()へのパラメータが正の場合、 クッキーは設定されるが、指定された秒数が経過しても、 クッキーは無効にならない。 クッキーの有効期間には、、"木, 9 14 30828 02:48:05"が設定されている。 (クッキー受信時の確認ダイアログで確認) ブラウザを再起動しても、クッキーは有効である。 # NN4.7では、指定された時間が経過するとクッキーは無効になる。
- Cookie.setMaxAge()へのパラメータに0を指定した場合、 クッキーが設定されたままになる。 ブラウザを再起動しても、クッキーは有効である。 クッキーの有効期間には、"木, 9 14 30828 02:48:05"が設定されている
NN4.7では、ブラウザはクッキーを受信した旨をダイアログで表示する。 しかし、その後のリクエストではこのクッキーを送信しない。(期待通り)「原因」
Internet Explorer 5(version 3, 4では調べていない)では、 次のようにタイムゾーンがJSTで指定されている有効期限付きSet-Cookieヘッダを 正しく解釈できません。
Set-Cookie:NAME=VALUE; expires=Tuesday,28-Feb-2000 19:00:00 JSTIE5では、タイムゾーンがGMTである場合は、クッキーの有効期限が正しく設定されます。 (タイムゾーンがその他の場合の動作は、調べていません。)
[12] 教えて!北京五輪「みんなにQ&A」 クッキーの有効期限の記述について ( 版) <http://qa.asahi.com/qa1158822.html>
IEでは、曜日は確かに 無視されているようでした(曜日をいろいろ変えても 設定日時には、クッキーが削除されました)。
[13] [JavaScript + Cookie]実は有効期限指定がすごく簡単だった件について / 文系大学的IT系の悲哀 (LiosK 著, 版) <http://liosk.blog103.fc2.com/blog-entry-22.html>
手元にあるIE6, Firefox2, Opera9で確認済み。Date#toUTCStringで有効期限が指定できるなら楽だ。
[23] Java 6のHttpCookieの野郎は、日本ではexpires指定ありのクッキーを処理できていない。 - 片っ端から忘れていけばいいじゃない。 ( (0xC000013A 著, 版)) <http://0xc000013a.blog96.fc2.com/blog-entry-131.html>
[36] Expires=Sat, 20 Feb 2016 02:25:16 UTC
nicovideo.jp が使っている形式。