-
Notifications
You must be signed in to change notification settings - Fork 4
/
56.txt
1698 lines (1404 loc) · 85.2 KB
/
56.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
'''HTTP State Management Mechanism'''
- Network Working Group
-Request for Comments: [DEL(rfc2965)[2109]] [INS(rfc2965)[2965]]
-[INS(rfc2965)[Obsoletes: 2109]]
- Category: Standards Track
-[INS(rfc2965)[D. Kristol]]
- Bell Laboratories, Lucent Technologies
- L. Montulli
-[DEL(rfc2965)[Netscape Communications]]
-[INS(rfc2965)[Epinions.com, Inc.]]
-[DEL(rfc2965)[February 1997]]
-[INS(rfc2965)[October 2000]]
* Status of this Memo
> This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
[INS[
この[[文書]]は [[IETF]] が発行した [[RFC]] の翻訳文を含んでいます。
翻訳は[[規定]]の一部ではありません。
原文:
- [[RFC 2109]] <http://tools.ietf.org/html/rfc2109>
- [[RFC 2965]] <http://tools.ietf.org/html/rfc2965>
]INS]
[INS(rfc2965)[
*Copyright Notice
> Copyright (C) The Internet Society (2000). All Rights Reserved.
*IESG Note
> The IESG notes that this mechanism makes use of the .local top-level
domain (TLD) internally when handling host names that don't contain
any dots, and that this mechanism might not work in the expected way
should an actual .local TLD ever be registered.
]INS]
*[DEL(rfc2965)[1. ABSTRACT]] [INS(rfc2965)[Abstract]]
[DEL(rfc2965)[
> This document specifies a way to create a stateful session with
HTTP requests and responses. It describes two new headers, Cookie and
Set-Cookie, which carry state information between participating
origin servers and user agents. The method described here differs
from Netscape's Cookie proposal, but it can interoperate with
HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL
section.)
]DEL]
[INS(rfc2965)[
>Hypertext Transfer Protocol (HTTP) requests and responses. It
describes three new headers, Cookie, Cookie2, and Set-Cookie2, which
carry state information between participating origin servers and user
agents. The method described here differs from Netscape's Cookie
proposal [Netscape], but it can interoperate with HTTP/1.0 user
agents that use Netscape's method. (See the HISTORICAL section.)
> This document reflects implementation experience with RFC 2109 and
obsoletes it.
]INS]
*[DEL(rfc2965)[2.]] [INS(rfc2965)[1.]] TERMINOLOGY
[PRE[
- The terms user agent, client, server, proxy, and origin server have
- the same meaning as in the HTTP/1.0 specification.
+ The terms user agent, client, server, proxy, origin server, and
+ http_URL have the same meaning as in the HTTP/1.1 specification
+ [RFC2616]. The terms abs_path and absoluteURI have the same meaning
+ as in the URI Syntax specification [RFC2396].
- Fully-qualified host name (FQHN) means either the fully-qualified
- domain name (FQDN) of a host (i.e., a completely specified domain
- name ending in a top-level domain such as .com or .uk), or the
- numeric Internet Protocol (IP) address of a host. The fully
- qualified domain name is preferred; use of numeric IP addresses is
- strongly discouraged.
+ Host name (HN) means either the host domain name (HDN) or the numeric
+ Internet Protocol (IP) address of a host. The fully qualified domain
+ name is preferred; use of numeric IP addresses is strongly
+ discouraged.
The terms request-host and request-URI refer to the values the client
would send to the server as, respectively, the host (but not port)
and abs_path portions of the absoluteURI (http_URL) of the HTTP
- request line. Note that request-host must be a FQHN.
+ request line. Note that request-host is a HN.
- Hosts names can be specified either as an IP address or a FQHN
- string. Sometimes we compare one host name with another. Host A's
- name domain-matches host B's if
+ The term effective host name is related to host name. If a host name
+ contains no dots, the effective host name is that name with the
+ string .local appended to it. Otherwise the effective host name is
+ the same as the host name. Note that all effective host names
+ contain at least one dot.
- * both host names are IP addresses and their host name strings match
- exactly; or
+ The term request-port refers to the port portion of the absoluteURI
+ (http_URL) of the HTTP request line. If the absoluteURI has no
+ explicit port, the request-port is the HTTP default, 80. The
+ request-port of a cookie is the request-port of the request in which
+ a Set-Cookie2 response header was returned to the user agent.
- * both host names are FQDN strings and their host name strings match
- exactly; or
+ Host names can be specified either as an IP address or a HDN string.
+ Sometimes we compare one host name with another. (Such comparisons
+ SHALL be case-insensitive.) Host A's name domain-matches host B's if
- * A is a FQDN string and has the form NB, where N is a non-empty name
- string, B has the form .B', and B' is a FQDN string. (So, x.y.com
- domain-matches .y.com but not y.com.)
+ * their host name strings string-compare equal; or
+
+ * A is a HDN string and has the form NB, where N is a non-empty
+ name string, B has the form .B', and B' is a HDN string. (So,
+ x.y.com domain-matches .Y.com but not Y.com.)
Note that domain-match is not a commutative operation: a.b.c.com
domain-matches .c.com, but not the reverse.
+ The reach R of a host name H is defined as follows:
+
+ * If
+
+ - H is the host domain name of a host; and,
+
+ - H has the form A.B; and
+
+ - A has no embedded (that is, interior) dots; and
+
+ - B has at least one embedded dot, or B is the string "local".
+ then the reach of H is .B.
+
+ * Otherwise, the reach of H is H.
+
+ For two strings that represent paths, P1 and P2, P1 path-matches P2
+ if P2 is a prefix of P1 (including the case where P1 and P2 string-
+ compare equal). Thus, the string /tec/waldo path-matches /tec.
]PRE]
Because it was used in Netscape's original implementation of state
management, we will use the term cookie to refer to the state
information that passes between an origin server and user agent, and
that gets stored by the user agent.
**1.1 Requirements
[INS(rfc2965)[
The key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
]INS]
*[DEL(rfc2965)[3.]] [INS(rfc2965)[2.]] STATE AND SESSIONS
[4]
>
This document describes a way to create stateful sessions with HTTP
requests and responses. Currently, HTTP servers respond to each
client request without relating that request to previous or
subsequent requests; [DEL(rfc2965)[the technique]] [INS(rfc2965)[the state management mechanism]]
allows clients and servers that wish to exchange state information to place HTTP
requests and responses within a larger context, which we term a
"session". This context might be used to create, for example, a
"shopping cart", in which user selections can be aggregated before
purchase, or a magazine browsing system, in which a user's previous
reading affects which offerings are presented.
この文書は [[HTTP]] の[[要求]]と[[応答]]で[RUBYB[[[状態]]を持った[[セッション]]]@en[stateful session]]を作る方法を説明します。
現在、[[HTTP]] [[鯖]]は[[クライアント]]の[[要求]]それぞれに対して、
以前や以後の[[要求]]と関連付けすることなく[[応答]]しています。 [DEL(rfc2965)[この技術]][INS(rfc2965)[この状態管理機構]]によって、
[RUBYB[[[状態]]]@en[state]]情報を交換したいと思う[[クライアント]]や[[鯖]]は、
[[HTTP]] の[[要求]]や[[応答]]の群をより大きな[RUBYB[文脈]@en[context]]に配置できるようになります。
この文脈を[DFN[[RUBYB[セッション]@en[session]]]]と呼びます。
この文脈は例えば「[[買い物籠]]」といって利用者が選択したものを購入前に集めておくために使うことができますし、
雑誌閲覧システムで[[利用者]]の閲覧履歴に基づきどの雑誌を候補として提示するかを決めるために使うこともできます。
[DEL(rfc2965)[
> There are, of course, many different potential contexts and thus many
different potential types of session. The designers' paradigm for
sessions created by the exchange of cookies has these key attributes:
= Each session has a beginning and an end.
= Each session is relatively short-lived.
= Either the user agent or the origin server may terminate a session.
= The session is implicit in the exchange of state information.
もちろん文脈となり得るものは色々ありますし、ひいては[[セッション]]の種類も色々となるでしょう。
[[Cookie]] の交換によって作られる[[セッション]]の設計者のパラダイムにはいくつか鍵となる属性がありmさう。
= 各[[セッション]]には始まりと終わりがあります。
= 各[[セッション]]は比較的短期間で終わります。
= [[利用者エージェント]]と[[起源鯖]]のどちらが[[セッション]]を終了させても構いません。
= [[セッション]]は[[状態]]情報の交換の中に暗示的に存在します。
]DEL]
[INS(rfc2965)[
> Neither clients nor servers are required to support cookies. A
server MAY refuse to provide content to a client that does not return
the cookies it sends.
[[クライアント]]と[[鯖]]のいずれも、[[Cookie]] への対応は必須ではありません。
[[鯖]]は、自身が送信した [[Cookie]] を返さない[[クライアント]]に[[内容]]を提供することを拒んでも[['''構いません''']]。
]INS]
*[DEL(rfc2965)[4. OUTLINE]] [INS(rfc2965)[3. DESCRIPTION]]
[PRE[
- We outline here a way for an origin server to send state information
+ We describe here a way for an origin server to send state information
to the user agent, and for the user agent to return the state
information to the origin server. The goal is to have a minimal
+ impact on HTTP and user agents.
- impact on HTTP and user agents. Only origin servers that need to
- maintain sessions would suffer any significant impact, and that
- impact can largely be confined to Common Gateway Interface (CGI)
- programs, unless the server provides more sophisticated state
- management support. (See Implementation Considerations, below.)
]PRE]
**[DEL(rfc2965)[4.1]] [INS(rfc2965)[3.1]] Syntax: General
> The two state management headers, Set-Cookie[INS(rfc2965)[2]] and Cookie, have common
syntactic properties involving attribute-value pairs. The following
grammar uses the notation, and tokens DIGIT (decimal digits)[INS(rfc2965)[,]] [DEL(rfc2965)[and]] token
(informally, a sequence of non-special, non-white space characters)[INS(rfc2965)[, and http_URL]]
from the HTTP/1.1 specification [DEL(rfc2965)[ [RFC 2068] ]] [INS(rfc2965)[ [RFC2616] ]] to describe their syntax.
2つの状態管理頭、 [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
と [CODE(HTTP)[[[Cookie]]]] は、両方共構文的に同じ属性と値の組を使っています。
次の文法は、構文を説明するために [[HTTP/1.1]]
仕様書の記法と字句 [CODE(ABNF)[[[DIGIT]]]] (十進数字)、
[CODE(ABNF)[[[token]]]] (簡単に言えば特殊でない[[空白]]でない[[文字]]の列)[INS(rfc2965)[、 [CODE(ABNF)[[[http_URL]]]]]]
を使います。
>
- av-pairs = av-pair *(";" av-pair)
- av-pair = attr ["=" value] ; optional value
- attr = token
- [DEL(rfc2965)[value = word]]
- [DEL(rfc2965)[word = token | quoted-string]]
- [INS(rfc2965)[value = token | quoted-string]]
> Attributes (names) (attr) are case-insensitive. White space is
permitted between tokens. Note that while the above syntax
description shows value as optional, most attrs require them.
属性(名) ([CODE(ABNF)[attr]]) は大文字・小文字を区別しません。
字句の間に[[空白]]が認められます。この構文記述は値を省略可能としていますが、
ほとんどの [CODE(ABNF)[attr]] では必須であることに注意して下さい。
> NOTE: The syntax above allows whitespace between the attribute and
the = sign.
注意: この構文は属性と [CODE(char)[[[=]]]] 記号の間に[[空白]]を認めています。
*[DEL(rfc2965)[4.2]] [INS(rfc2965)[3.2]] Origin Server Role
**[DEL(rfc2965)[4.2.1]] [INS(rfc2965)[3.2.1]] General
> The origin server initiates a session, if it so desires. [DEL(rfc2965)[(Note that "session" here does not refer to a persistent network connection but to a logical session created from HTTP requests and responses. The presence or absence of a persistent connection should have no effect on the use of cookie-derived sessions).]]
To [DEL(rfc2965)[initiate a session]] [INS(rfc2965)[do so]], [DEL(rfc2965)[the origin server]] [INS(rfc2965)[it]]
returns an extra response header to the client, [DEL(rfc2965)[Set-Cookie]] [INS(rfc2965)[Set-Cookie2]].
(The details follow later.)
[[起源鯖]]は必要なら[[セッション]]を初期化します。 [DEL(rfc2965)[(ここで[Q[[[セッション]]]]は持続的なネットワーク接続を指すのではなく、 [[HTTP]] の[[要求]]や[[応答]]によって論理的に作られる[[セッション]]を指すことに注意。持続的接続であるか否かは cookie による[[セッション]]の使用と無関係であるべきです。)]]
[[セッション]]を初期化するために[[起源鯖]]は[[クライアント]]に [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
という応答頭を付け加えます。 (詳細は後述します。)
> A user agent returns a Cookie request header (see below) to the
origin server if it chooses to continue a session. The origin
server [DEL(rfc2965)[may]] [INS(rfc2965)[MAY]] ignore it or use it to determine the current state of the
session. It [DEL(rfc2965)[may]] [INS(rfc2965)[MAY]] send back to the client a [DEL(rfc2965)[Set-Cookie]] [INS(rfc2965)[Set-Cookie2]] response
header with the same or different information, or it [DEL(rfc2965)[may]] [INS(rfc2965)[MAY]] send
no [DEL(rfc2965)[Set-Cookie]] [INS(rfc2965)[Set-Cookie2]] header at all. The origin server effectively ends a
session by sending the client a [DEL(rfc2965)[Set-Cookie]] [INS(rfc2965)[Set-Cookie2]] header with Max-Age=0.
[[利用者エージェント]]は[[セッション]]を継続したければ[[起源鯖]]に
[CODE(HTTP)[[[Cookie]]]] 要求頭 (後述) を返します。[[起源鯖]]はこれを無視しても'''構いません'''し、
[[セッション]]の現在の状態を決定するために使っても'''構いません'''。
[[起源鯖]]は[[クライアント]]に同じ情報でも異なる情報でも [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
要求頭を送り返して'''構いません'''し、まったく [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
頭を送らなくても'''構いません'''。[[起源鯖]]は[[クライアント]]に
[CODE(HTTP)[[[Max-Age]]=0]] の [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
を送ることによって実効的に[[セッション]]を終了させることができます。
> Servers [DEL(rfc2965)[may]] [INS(rfc2965)[MAY]] return [DEL(rfc2965)[a Set-Cookie]] [INS(rfc2965)[Set-Cookie2]] response headers with any response.
User agents [DEL(rfc2965)[should]] [INS(rfc2965)[SHOULD]] send Cookie request headers, subject to other
rules detailed below, with every request.
[[鯖]]は任意の[[応答]]で [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
応答頭を返して'''構いません'''。[[利用者エージェント]]は後で詳述する規則に従って各[[要求]]において
[CODE(HTTP)[[[Cookie]]]] 要求頭を送る'''べきです'''。
> An origin server [DEL(rfc2965)[may]] [INS(rfc2965)[MAY]] include multiple [DEL(rfc2965)[Set-Cookie]] [INS(rfc2965)[Set-Cookie2]] headers in a
response. Note that an intervening gateway could fold multiple such
headers into a single header.
[[起源鯖]]は一つの[[応答]]に複数の [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
頭を含めて'''構いません'''。仲介する[[関門]]が複数の頭を一つの頭に畳むかもしれないことに注意して下さい。
*[DEL(rfc2965)[4.2.2 Set-Cookie]] [INS(rfc2965)[3.2.2 Set-Cookie2]] Syntax
> The syntax for the [DEL(rfc2965)[Set-Cookie]] [INS(rfc2965)[Set-Cookie2]]
response header is
応答頭 [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
の構文は次の通りです。
>
- [DEL(rfc2965)[set-cookie = "Set-Cookie:" cookies]]
- [INS(rfc2965)[set-cookie = "Set-Cookie2:" cookies]]
- cookies = 1#cookie
- cookie = NAME "=" VALUE *(";" [DEL(rfc2965)[cookie-av]] [INS(rfc2965)[set-cookie-av)]]
- NAME = attr
- VALUE = value
- [DEL(rfc2965)[cookie-av]] [INS(rfc2965)[set-cookie-av]] = "Comment" "=" value [INS(rfc2965)[| "CommentURL" "=" <"> http_URL <">]] [INS(rfc2965)[| "Discard"]] | "Domain" "=" value | "Max-Age" "=" value | "Path" "=" value [INS(rfc2965)[| "Port" [ "=" <"> portlist <"> ] ]] | "Secure" | "Version" "=" 1*DIGIT
- [INS(rfc2965)[portlist = 1#portnum]]
- [INS(rfc2965)[portnum = 1*DIGIT]]
> Informally, the [DEL(rfc2965)[Set-Cookie]] [INS(rfc2965)[Set-Cookie2]]
response header comprises the
token [DEL(rfc2965)[Set-Cookie]] [INS(rfc2965)[Set-Cookie2]],
followed by a comma-separated list of one or more cookies.
Each cookie begins with a NAME=VALUE pair, followed by zero or more
semi-colon-separated attribute-value pairs. The syntax for
attribute-value pairs was shown earlier. The specific attributes and
the semantics of their values follows. The NAME=VALUE attribute-value
pair [DEL(rfc2965)[must]] [INS(rfc2965)[MUST]]
come first in each cookie. The others, if present,
can occur in any order. If an attribute appears more than once in a
cookie, [DEL(rfc2965)[the behavior is undefined]] [INS(rfc2965)[the client SHALL use only the value associated with the first appearance of the attribute; a client MUST ignore values after the first]].
非公式には、 [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
応答頭は字句 [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
の後に読点で区切った一つ以上の [CODE(ABNF)[cookie]] の[[並び]]が続きます。
各 [CODE(ABNF)[cookie]] は [CODE(HTTP)[[VAR[NAME]]=[VAR[VALUE]]]]
の組1つで始まり、セミコロンで区切った属性・値の組が零個以上続きます。
属性・値の組の構文は先述の通りです。個々の属性とその値の意味は次で述べます。
[CODE(HTTP)[[VAR[NAME]]=[VAR[VALUE]]]] の組は各 [CODE(ABNF)[cookie]]
の最初に来なければ'''なりません'''。他のものを指定する場合はどんな順序でも構いません。
一つの [CODE(ABNF)[cookie]] 内に同じ属性が複数表れるときには、[DEL(rfc2965)[動作は未定義です]] [INS(rfc2965)[[[クライアント]]は最初に現れた属性に対応する値だけを使い、他の値は無視しなければ'''なりません''']]。
[INS(rfc2965)[
> The NAME of a cookie MAY be the same as one of the attributes in this
specification. However, because the cookie's NAME must come first in
a Set-Cookie2 response header, the NAME and its VALUE cannot be
confused with an attribute-value pair.
[CODE(ABNF)[cookie]] の [CODE(ABNF)[NAME]] はこの仕様の属性の名前と同じでも'''構いません'''。
しかし、 [CODE(ABNF)[cookie]] の [CODE(ABNF)[NAME]]
は [CODE(HTTP)[[[Set-Cookie2]]]] 応答頭の最初に来なければなりませんから、
[CODE(ABNF)[NAME]] と [CODE(ABNF)[VALUE]] を属性・値の組と混同することはありません。
]INS]
>
: NAME=VALUE: [DEL(rfc2965)[Required]] [INS(rfc2965)[REQUIRED]].
The name of the state information ("cookie") is NAME,
and its value is VALUE. NAMEs that begin with $ are
reserved [DEL(rfc2965)[for other uses]] and [DEL(rfc2965)[must not]] [INS[MUST NOT]]
be used by applications.
:[CODE(HTTP)[[VAR[NAME]]=[VAR[VALUE]]]]:
'''必須'''。状態情報 ([Q[cookie]]) の名前が [VAR[NAME]]
で、その値が [VAR[VALUE]] です。 [CODE(char)[$]]
で始まる [VAR[NAME]] は予約されており、[[応用]]が使用しては'''なりません'''。
> The VALUE is opaque to the user agent and may be anything the
origin server chooses to send, possibly in a server-selected
printable ASCII encoding. "Opaque" implies that the content is of
interest and relevance only to the origin server. The content
may, in fact, be readable by anyone that examines
the [DEL(rfc2965)[Set-Cookie]] [INS(rfc2965)[Set-Cookie2]]
header.
[VAR[VALUE]] は[[利用者エージェント]]には不透明であり、
[[起源鯖]]がどんなものでも送信することができ、
[[鯖]]が決めた [[ASCII]] [[符号化]]を行っていても構いません。
[Q[不透明]]というのは、内容が[[起源鯖]]だけが関心・関係するものということです。
内容は実際には [DEL(rfc2965)[[CODE(HTTP)[[[Set-Cookie]]]]]] [INS(rfc2965)[[CODE(HTTP)[[[Set-Cookie2]]]]]]
頭を調べた人誰にでも読むことができます。
>
: Comment=[DEL(rfc2965)[comment]] [INS(rfc2965)[value]]:[DEL(rfc2965)[Optional]] [INS(rfc2965)[OPTIONAL]].
Because cookies can [DEL(rfc2965)[contain]] [INS(rfc2965)[be used to derive or store]]
private information about a user,
the [DEL(rfc2965)[Cookie]] [INS(rfc2965)[value of the Comment]] attribute
allows an origin server to
document [DEL(rfc2965)[its intended use of a]] [INS(rfc2965)[how it intends to use the]]
cookie. The user can inspect the information to decide whether to
initiate or continue a session with this
cookie. [INS(rfc2965)[Characters in value MUST be in UTF-8 encoding. [RFC2279] ]]
:[CODE(HTTP)[Comment=[CODE(ABNF)[value]]]]:
'''任意選択'''。 Cookie は[[利用者]]に関する個人情報を得たり蓄積したりするために使うことができますから、
[CODE(HTTP)[[[Comment]]]] 属性の値を使って[[起源鯖]]はその [CODE(ABNF)[cookie]]
をどう使うことを想定しているのかを文書化できます。
[[利用者]]はこの情報を調べて、この [CODE(ABNF)[cookie]]
で[[セッション]]を初期化または継続するかどうかを決めることができます。 [INS(rfc2965)[[CODE(ABNF)[value]] の中の[[文字]]は [[UTF-8]] で[[符号化]]しなければ'''なりません'''。]]
[INS(rfc2965)[
>
: CommentURL="http_URL":
OPTIONAL. Because cookies can be used to derive or store private
information about a user, the CommentURL attribute allows an
origin server to document how it intends to use the cookie. The
user can inspect the information identified by the URL to decide
whether to initiate or continue a session with this cookie.
:[CODE(HTTP)[CommentURL="[CODE(ABNF)[http_URL]]"]]:
'''任意選択'''。 Cookie は[[利用者]]に関する個人情報を得たり蓄積したりするために使うことができますから、
[CODE(HTTP)[[[CommentURL]]]] 属性の値を使って[[起源鯖]]はその [CODE(ABNF)[cookie]]
をどう使うことを想定しているのかを文書化できます。
[[利用者]]はこの [[URL]] で識別される情報を調べて、この [CODE(ABNF)[cookie]]
で[[セッション]]を初期化または継続するかどうかを決めることができます。
>
: Discard:
OPTIONAL. The Discard attribute instructs the user agent to
discard the cookie unconditionally when the user agent terminates.
:[CODE(HTTP)[Discard]]:
'''任意選択'''。 [CODE(HTTP)[Discard]] 属性は[[利用者エージェント]]が終了するときにこの
[CODE(ABNF)[cookie]] を無条件で廃棄するよう[[利用者エージェント]]に指示します。
]INS]
>
: Domain=[DEL(rfc2965)[domain]] [INS(rfc2965)[value]]: [DEL(rfc2965)[Optional]] [INS(rfc2965)[OPTIONAL]].
The [INS(rfc2965)[value of the]]
Domain attribute specifies the domain for which the cookie is
valid. [DEL(rfc2965)[An explicitly specified domain must always start with a dot.]] [INS(rfc2965)[If an explicitly specified value does not start with a dot, the user agent supplies a leading dot.]]
:[CODE(HTTP)[Domain=[CODE(ABNF)[value]]]]:
'''任意選択'''。 [CODE(HTTP)[Domain]] 属性の値はこの [CODE(ABNF)[cookie]]
が妥当である[[ドメイン]]を指定します。[DEL(rfc2965)[明示的に[[ドメイン]]を指定する時は点で始まらなければなりません。]] [INS(rfc2965)[明示的に指定された値が点で始まらなければ、[[利用者エージェント]]は最初に点を補います。]]
>
: Max-Age=[DEL(rfc2965)[delta-seconds]] [INS(rfc2965)[value]]: [DEL(rfc2965)[Optional. The Max-Age attribute defines the lifetime of the cookie, in seconds. The delta-seconds value is]] [INS(rfc2965)[OPTIONAL. The value of the Max-Age attribute is delta-seconds, the lifetime of the cookie in seconds,]]
a decimal non-negative integer. [INS(rfc2965)[To handle cached cookies correctly, a client SHOULD calculate the age of the cookie according to the age calculation rules in the HTTP/1.1 specification [RFC2616].]] [DEL(rfc2965)[After delta-seconds seconds elapse,]] [INS(rfc2965)[When the age is greater than delta-seconds seconds,]]
the client [DEL(rfc2965)[should]] [INS(rfc2965)[SHOULD]] discard the cookie.
A value of zero means the cookie [DEL(rfc2965)[should]] [INS(rfc2965)[SHOULD]]
be discarded immediately.
:[CODE(HTTP)[Max-Age=[CODE(ABNF)[value]]]]:
'''任意選択'''。 [CODE(HTTP)[Max-Age]] 属性の値は
[CODE(ABNF)[[[delta-seconds]]]] で、この [CODE(ABNF)[cookie]]
の[[寿命]]を[[秒]]数 (非負十進整数) で指定します。 [INS(rfc2965)[キャッシュされた cookie を正しく扱うために[[クライアント]]は cookie の[[齢]]を [[HTTP/1.1]] 仕様の[[齢]]計算規則に従って計算する'''べきです'''。]]
[[齢]]が [CODE(ABNF)[delta-seconds]] 秒よりも大きければ、
[[クライアント]]はその cookie を捨てる'''べきです'''。
値が零であればその cookie を直ぐに捨てる'''べきである'''ことを表します。
>
: Path=[DEL(rfc2965)[path]] [INS(rfc2965)[value]]:[DEL(rfc2965)[Optional]] [INS(rfc2965)[OPTIONAL]]. The [INS(rfc2965)[value of the]] Path attribute
specifies the subset of URLs [INS(rfc2965)[on the origin server]] to which this cookie applies.
:[CODE(HTTP)[Path=[CODE(ABNF)[value]]]]:
'''任意選択'''。 [CODE(HTTP)[[[Path]]]] 属性の値は[[起源鯖]]の [[URL]]
の[[部分集合]]であってその cookie が適用される部分を指定します。
[INS(rfc2965)[
>
: Port[="portlist"]:
OPTIONAL. The Port attribute restricts the port to which a cookie
may be returned in a Cookie request header. Note that the syntax
REQUIREs quotes around the OPTIONAL portlist even if there is only
one portnum in portlist.
:[CODE(HTTP)[Port'''['''="[CODE(ABNF)[portlist]]"''']''']]:
'''任意選択'''。 [CODE(HTTP)[Port]] 属性は cookie
を [CODE(HTTP)[[[Cookie]]]] 要求頭で返してもよい[[ポート]]を制限します。
構文は'''任意選択'''である [CODE(ABNF)[portlist]] 中に [CODE(ABNF)[portnum]]
が1つだけしかない場合でも引用符が'''必須'''であることに注意して下さい。
]INS]
>
: Secure: [DEL(rfc2965)[Optional]] [INS(rfc2965)[OPTIONAL]].
The Secure attribute (with no value) directs the user
agent to use only (unspecified) secure means to contact the origin
server whenever it sends back this cookie[INS(rfc2965)[, to protect the confidentially and authenticity of the information in the cookie]].
:[CODE(HTTP)[Secure]]:'''任意選択'''。
[CODE(HTTP)[[[Secure]]]] 属性 (値なし) は[[利用者エージェント]]にこの
cookie を送り返す時には [INS(rfc2965)[cookie 内の情報の機密性と信頼性を護るため]]
(未指定の) 安全な手段を使ってのみ[[起源鯖]]に接触をとるよう指示します。
> The user agent (possibly [DEL(rfc2965)[under the user's control]] [INS(rfc2965)[with user interaction]]) [DEL(rfc2965)[may]] [INS(rfc2965)[MAY]]
determine what level of security it considers appropriate for "secure" cookies.
The Secure attribute should be considered security advice from the
server to the user agent, indicating that it is in the session's
interest to protect the cookie contents. [INS(rfc2965)[When it sends a "secure" cookie back to a server, the user agent SHOULD use no less than the same level of security as was used when it received the cookie from the server.]]
[[利用者エージェント]]は (おそらく利用者との対話により)
[Q[安全]]な cookie に適当な安全の水準を決定して'''構いません'''。
[CODE(HTTP)[[[Secure]]]] 属性は[[セッション]]の中で cookie
の内容を保護することを示す[[鯖]]から[[利用者エージェント]]への助言と考えるべきです。[INS(rfc2965)[[[利用者エージェント]]が[[鯖]]に[Q[安全]]な cookie を送り返す時は、その cookie を[[鯖]]から受信した時に使われたのと同等以上の安全の水準とする'''べきです'''。]]
>
: Version=[DEL(rfc2965)[version]] [INS(rfc2965)[value]]:[DEL(rfc2965)[Required]] [INS(rfc2965)[REQUIRED]].
The [INS(rfc2965)[value of the]] Version attribute, a decimal integer,
identifies [DEL(rfc2965)[to which]] version of the state management
specification [INS(rfc2965)[to which]] the cookie conforms. For this
specification, Version=1 applies.
:[CODE(HTTP)[Version=[CODE(ABNF)[value]]]]:
'''必須'''。 [CODE(HTTP)[[[Version]]]] 属性は十進整数で、
その [CODE(ABNF)[[[cookie]]]] が適合する状態管理仕様の版を識別します。
この仕様では [CODE(HTTP)[Version=1]] とします。
***[DEL(rfc2965)[4.2.3]] [INS(rfc2965)[3.2.3]] Controlling Caching
[PRE[
An origin server must be cognizant of the effect of possible caching
- of both the returned resource and the Set-Cookie header.
+ of both the returned resource and the Set-Cookie2 header.
Caching "public" documents is desirable. For example, if the origin server
wants to use a public document such as a "front door" page as
a sentinel to indicate the beginning of a session for which a
- Set-Cookie response header must be generated, the page should
+ Set-Cookie2 response header must be generated, the page SHOULD
be stored in caches "pre-expired" so that the origin
server will see further requests. "Private documents", for example those
- that contain information strictly private to a session, should not
+ that contain information strictly private to a session, SHOULD NOT
be cached in shared caches.
- If the cookie is intended for use by a single user, the Set-cookie
+ If the cookie is intended for use by a single user, the Set-Cookie2
- header should not be cached. A Set-cookie header that is intended
+ header SHOULD NOT be cached. A Set-Cookie2 header that is intended
- to be shared by multiple users may be cached.
+ to be shared by multiple users MAY be cached.
- The origin server should send the following additional HTTP/1.1
+ The origin server SHOULD send the following additional HTTP/1.1
response headers, depending on circumstances:
- * To suppress caching of the Set-Cookie header: Cache-control: no-
+ * To suppress caching of the Set-Cookie2 header:
- cache="set-cookie".
+ Cache-control: no-cache="set-cookie2"
and one of the following:
- * To suppress caching of a private document in shared caches: Cache-
- control: private.
+ * To suppress caching of a private document in shared caches:
+
+ Cache-control: private
* To allow caching of a document and require that it be validated
- before returning it to the client: Cache-control: must-revalidate.
+ before returning it to the client:
- * To allow caching of a document, but to require that proxy caches
- (not user agent caches) validate it before returning it to the
- client: Cache-control: proxy-revalidate.
+ Cache-Control: must-revalidate, max-age=0
+
+ * To allow caching of a document, but to require that proxy
+ caches (not user agent caches) validate it before returning it
+ to the client:
+
+ Cache-Control: proxy-revalidate, max-age=0
* To allow caching of a document and request that it be validated
before returning it to the client (by "pre-expiring" it):
- Cache-control: max-age=0. Not all caches will revalidate the
- document in every case.
- HTTP/1.1 servers must send Expires: old-date (where old-date is a
- date long in the past) on responses containing Set-Cookie response
+ Cache-control: max-age=0
+
+ Not all caches will revalidate the document in every case.
+
+ HTTP/1.1 servers MUST send Expires: old-date (where old-date is a
+ date long in the past) on responses containing Set-Cookie2 response
headers unless they know for certain (by out of band means) that
- there are no downsteam HTTP/1.0 proxies. HTTP/1.1 servers may send
- other Cache-Control directives that permit caching by HTTP/1.1
- proxies in addition to the Expires: old-date directive; the Cache-
- Control directive will override the Expires: old-date for HTTP/1.1
- proxies.
+ there are no HTTP/1.0 proxies in the response chain. HTTP/1.1
+ servers MAY send other Cache-Control directives that permit caching
+ by HTTP/1.1 proxies in addition to the Expires: old-date directive;
+ the Cache-Control directive will override the Expires: old-date for
+ HTTP/1.1 proxies.
]PRE]
** [DEL(rfc2965)[4.3]] [INS(rfc2965)[3.3]] User Agent Role
*** [DEL(rfc2965)[4.3.1 Interpreting Set-Cookie]] [INS(rfc2965)[3.3.1 Interpreting Set-Cookie2]]
[PRE[
- The user agent keeps separate track of state information that arrives
- via Set-Cookie response headers from each origin server (as
- distinguished by name or IP address and port). The user agent
- applies these defaults for optional attributes that are missing:
+ The user agent keeps separate track
+ of state information that arrives via Set-Cookie2 response headers
+ from each origin server (as distinguished by name or IP address and
+ port). The user agent MUST ignore attribute-value pairs whose
+ attribute it does not recognize. The user agent applies these
+ defaults for optional attributes that are missing:
- VersionDefaults to "old cookie" behavior as originally specified by
- Netscape. See the HISTORICAL section.
+ Discard The default behavior is dictated by the presence or absence
+ of a Max-Age attribute.
- Domain Defaults to the request-host. (Note that there is no dot at
- the beginning of request-host.)
+ Domain Defaults to the effective request-host. (Note that because
+ there is no dot at the beginning of effective request-host,
+ the default Domain can only domain-match itself.)
Max-AgeThe default behavior is to discard the cookie when the user
agent exits.
Path Defaults to the path of the request URL that generated the
- Set-Cookie response, up to, but not including, the
- right-most /.
+ Set-Cookie2 response, up to and including the right-most /.
- Secure If absent, the user agent may send the cookie over an
+
+ Port The default behavior is that a cookie MAY be returned to any
+ request-port.
+
+ Secure If absent, the user agent MAY send the cookie over an
insecure channel.
]PRE]
*** [DEL(rfc2695)[4.3.2 Rejecting Cookies]] [INS(rfc2695)[3.3.2]]
[PRE[
- To prevent possible security or privacy violations, a user agent
- rejects a cookie (shall not store its information) if any of the
- following is true:
+ To prevent possible security or privacy
+ violations, a user agent rejects a cookie according to rules below.
+ The goal of the rules is to try to limit the set of servers for which
+ a cookie is valid, based on the values of the Path, Domain, and Port
+ attributes and the request-URI, request-host and request-port.
+ A user agent rejects (SHALL NOT store its information) if the Version
+ attribute is missing. Moreover, a user agent rejects (SHALL NOT
+ store its information) if any of the following is true of the
+ attributes explicitly present in the Set-Cookie2 response header:
- * The value for the Path attribute is not a prefix of the request-
- URI.
+ * The value for the Path attribute is not a prefix of the
+ request-URI.
- * The value for the Domain attribute contains no embedded dots or
- does not start with a dot.
+ * The value for the Domain attribute contains no embedded dots,
+ and the value is not .local.
- * The value for the request-host does not domain-match the Domain
- attribute.
+ * The effective host name that derives from the request-host does
+ not domain-match the Domain attribute.
- * The request-host is a FQDN (not IP address) and has the form HD,
+ * The request-host is a HDN (not IP address) and has the form HD,
where D is the value of the Domain attribute, and H is a string
that contains one or more dots.
+ * The Port attribute has a "port-list", and the request-port was
+ not in the list.
+
Examples:
- * A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com
+ * A Set-Cookie2 from request-host y.x.foo.com for Domain=.foo.com
would be rejected, because H is y.x and contains a dot.
- * A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
- be accepted.
+ * A Set-Cookie2 from request-host x.foo.com for Domain=.foo.com
+ would be accepted.
- * A Set-Cookie with Domain=.com or Domain=.com., will always be
+ * A Set-Cookie2 with Domain=.com or Domain=.com., will always be
rejected, because there is no embedded dot.
- * A Set-Cookie with Domain=ajax.com will be rejected because the
- value for Domain does not begin with a dot.
+ * A Set-Cookie2 with Domain=ajax.com will be accepted, and the
+ value for Domain will be taken to be .ajax.com, because a dot
+ gets prepended to the value.
+ * A Set-Cookie2 with Port="80,8000" will be accepted if the
+ request was made to port 80 or 8000 and will be rejected
+ otherwise.
+ * A Set-Cookie2 from request-host example for Domain=.local will
+ be accepted, because the effective host name for the request-
+ host is example.local, and example.local domain-matches .local.
]PRE]
[PRE[
-4.3.3 Cookie Management
- If a user agent receives a Set-Cookie response header whose NAME is
- the same as a pre-existing cookie, and whose Domain and Path
- attribute values exactly (string) match those of a pre-existing
- cookie, the new cookie supersedes the old. However, if the Set-
- Cookie has a value for Max-Age of zero, the (old and new) cookie is
- discarded. Otherwise cookies accumulate until they expire (resources
- permitting), at which time they are discarded.
+
+ 3.3.3 Cookie Management If a user agent receives a Set-Cookie2
+ response header whose NAME is the same as that of a cookie it has
+ previously stored, the new cookie supersedes the old when: the old
+ and new Domain attribute values compare equal, using a case-
+ insensitive string-compare; and, the old and new Path attribute
+ values string-compare equal (case-sensitive). However, if the Set-
+ Cookie2 has a value for Max-Age of zero, the (old and new) cookie is
+ discarded. Otherwise a cookie persists (resources permitting) until
+ whichever happens first, then gets discarded: its Max-Age lifetime is
+ exceeded; or, if the Discard attribute is set, the user agent
+ terminates the session.
Because user agents have finite space in which to store cookies, they
- may also discard older cookies to make space for newer ones, using,
+ MAY also discard older cookies to make space for newer ones, using,
for example, a least-recently-used algorithm, along with constraints
on the maximum number of cookies that each origin server may set.
- If a Set-Cookie response header includes a Comment attribute, the
- user agent should store that information in a human-readable form
- with the cookie and should display the comment text as part of a
+ If a Set-Cookie2 response header includes a Comment attribute, the
+ user agent SHOULD store that information in a human-readable form
+ with the cookie and SHOULD display the comment text as part of a
cookie inspection user interface.
- User agents should allow the user to control cookie destruction. An
- infrequently-used cookie may function as a "preferences file" for
- network applications, and a user may wish to keep it even if it is
- the least-recently-used cookie. One possible implementation would be
- an interface that allows the permanent storage of a cookie through a
- checkbox (or, conversely, its immediate destruction).
+ If a Set-Cookie2 response header includes a CommentURL attribute, the
+ user agent SHOULD store that information in a human-readable form
+ with the cookie, or, preferably, SHOULD allow the user to follow the
+ http_URL link as part of a cookie inspection user interface.
+
+ The cookie inspection user interface may include a facility whereby a
+ user can decide, at the time the user agent receives the Set-Cookie2
+ response header, whether or not to accept the cookie. A potentially
+ confusing situation could arise if the following sequence occurs:
+
+ * the user agent receives a cookie that contains a CommentURL
+ attribute;
+
+ * the user agent's cookie inspection interface is configured so
+ that it presents a dialog to the user before the user agent
+ accepts the cookie;
+
+
+
+
+ * the dialog allows the user to follow the CommentURL link when
+ the user agent receives the cookie; and,
+
+ * when the user follows the CommentURL link, the origin server
+ (or another server, via other links in the returned content)
+ returns another cookie.
+
+ The user agent SHOULD NOT send any cookies in this context. The user
+ agent MAY discard any cookie it receives in this context that the
+ user has not, through some user agent mechanism, deemed acceptable.
+
+ User agents SHOULD allow the user to control cookie destruction, but
+ they MUST NOT extend the cookie's lifetime beyond that controlled by
+ the Discard and Max-Age attributes. An infrequently-used cookie may
+ function as a "preferences file" for network applications, and a user
+ may wish to keep it even if it is the least-recently-used cookie. One
+ possible implementation would be an interface that allows the
+ permanent storage of a cookie through a checkbox (or, conversely, its
+ immediate destruction).
Privacy considerations dictate that the user have considerable
control over cookie management. The PRIVACY section contains more
information.
-4.3.4 Sending Cookies to the Origin Server
-
- When it sends a request to an origin server, the user agent sends a
- Cookie request header to the origin server if it has cookies that are
- applicable to the request, based on
+ 3.3.4 Sending Cookies to the Origin Server When it sends a request
+ to an origin server, the user agent includes a Cookie request header
+ if it has stored cookies that are applicable to the request, based on
- * the request-host;
+ * the request-host and request-port;
* the request-URI;
* the cookie's age.
The syntax for the header is:
- cookie = "Cookie:" cookie-version
- 1*((";" | ",") cookie-value)
- cookie-value = NAME "=" VALUE [";" path] [";" domain]
+cookie = "Cookie:" cookie-version 1*((";" | ",") cookie-value)
+cookie-value = NAME "=" VALUE [";" path] [";" domain] [";" port]
cookie-version = "$Version" "=" value
NAME = attr
VALUE = value
path = "$Path" "=" value
domain = "$Domain" "=" value
+port = "$Port" [ "=" <"> value <"> ]
- The value of the cookie-version attribute must be the value from the
- Version attribute, if any, of the corresponding Set-Cookie response
- header. Otherwise the value for cookie-version is 0. The value for
- the path attribute must be the value from the Path attribute, if any,
- of the corresponding Set-Cookie response header. Otherwise the
- attribute should be omitted from the Cookie request header. The
- value for the domain attribute must be the value from the Domain
- attribute, if any, of the corresponding Set-Cookie response header.
- Otherwise the attribute should be omitted from the Cookie request
- header.
+ The value of the cookie-version attribute MUST be the value from the
+ Version attribute of the corresponding Set-Cookie2 response header.
+ Otherwise the value for cookie-version is 0. The value for the path
+ attribute MUST be the value from the Path attribute, if one was
+ present, of the corresponding Set-Cookie2 response header. Otherwise
+ the attribute SHOULD be omitted from the Cookie request header. The
+ value for the domain attribute MUST be the value from the Domain
+ attribute, if one was present, of the corresponding Set-Cookie2
+ response header. Otherwise the attribute SHOULD be omitted from the
+ Cookie request header.
- Note that there is no Comment attribute in the Cookie request header
- corresponding to the one in the Set-Cookie response header. The user
- agent does not return the comment information to the origin server.
+ The port attribute of the Cookie request header MUST mirror the Port
+ attribute, if one was present, in the corresponding Set-Cookie2
+ response header. That is, the port attribute MUST be present if the
+ Port attribute was present in the Set-Cookie2 header, and it MUST
+ have the same value, if any. Otherwise, if the Port attribute was
+ absent from the Set-Cookie2 header, the attribute likewise MUST be
+ omitted from the Cookie request header.
- The following rules apply to choosing applicable cookie-values from
- among all the cookies the user agent has.
+ Note that there is neither a Comment nor a CommentURL attribute in
+ the Cookie request header corresponding to the ones in the Set-
+ Cookie2 response header. The user agent does not return the comment
+ information to the origin server.
- Domain Selection
- The origin server's fully-qualified host name must domain-match
- the Domain attribute of the cookie.
+ The user agent applies the following rules to choose applicable
+ cookie-values to send in Cookie request headers from among all the
+ cookies it has received.
- Path Selection
- The Path attribute of the cookie must match a prefix of the
- request-URI.
+ Domain Selection
+ The origin server's effective host name MUST domain-match the
+ Domain attribute of the cookie.
- Max-Age Selection
- Cookies that have expired should have been discarded and thus
- are not forwarded to an origin server.
+ Port Selection
+ There are three possible behaviors, depending on the Port
+ attribute in the Set-Cookie2 response header:
+ 1. By default (no Port attribute), the cookie MAY be sent to any
+ port.
+ 2. If the attribute is present but has no value (e.g., Port), the
+ cookie MUST only be sent to the request-port it was received
+ from.
+ 3. If the attribute has a port-list, the cookie MUST only be
+ returned if the new request-port is one of those listed in
+ port-list.
+ Path Selection
+ The request-URI MUST path-match the Path attribute of the cookie.
+ Max-Age Selection
+ Cookies that have expired should have been discarded and thus are
+ not forwarded to an origin server.
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.
Note: For backward compatibility, the separator in the Cookie header
- is semi-colon (;) everywhere. A server should also accept comma (,)
+ is semi-colon (;) everywhere. A server SHOULD also accept comma (,)
as the separator between cookie-values for future compatibility.
+ 3.3.5 Identifying What Version is Understood: Cookie2 The Cookie2
+ request header facilitates interoperation between clients and servers
+ that understand different versions of the cookie specification. When
+ the client sends one or more cookies to an origin server, if at least
+ one of those cookies contains a $Version attribute whose value is
+ different from the version that the client understands, then the
+ client MUST also send a Cookie2 request header, the syntax for which
+ is
+
+ cookie2 = "Cookie2:" cookie-version
+
+ Here the value for cookie-version is the highest version of cookie
+ specification (currently 1) that the client understands. The client
+ needs to send at most one such request header per request.
-4.3.5 Sending Cookies in Unverifiable Transactions
+ 3.3.6 Sending Cookies in Unverifiable Transactions Users MUST have
+ control over sessions in order to ensure privacy. (See PRIVACY
+ section below.) To simplify implementation and to prevent an
+ additional layer of complexity where adequate safeguards exist,
+ however, this document distinguishes between transactions that are
+ verifiable and those that are unverifiable. A transaction is
+ verifiable if the user, or a user-designated agent, has the option to
+ review the request-URI prior to its use in the transaction. A
+ transaction is unverifiable if the user does not have that option.
+ Unverifiable transactions typically arise when a user agent
+ automatically requests inlined or embedded entities or when it
+ resolves redirection (3xx) responses from an origin server.
+ Typically the origin transaction, the transaction that the user
+ initiates, is verifiable, and that transaction may directly or
+ indirectly induce the user agent to make unverifiable transactions.
- Users must have control over sessions in order to ensure privacy.
- (See PRIVACY section below.) To simplify implementation and to
- prevent an additional layer of complexity where adequate safeguards
- exist, however, this document distinguishes between transactions that
- are verifiable and those that are unverifiable. A transaction is
- verifiable if the user has the option to review the request-URI prior
- to its use in the transaction. A transaction is unverifiable if the
- user does not have that option. Unverifiable transactions typically
- arise when a user agent automatically requests inlined or embedded
- entities or when it resolves redirection (3xx) responses from an
- origin server. Typically the origin transaction, the transaction
- that the user initiates, is verifiable, and that transaction may
- directly or indirectly induce the user agent to make unverifiable
- transactions.
+ An unverifiable transaction is to a third-party host if its request-
+ host U does not domain-match the reach R of the request-host O in the
+ origin transaction.
- When it makes an unverifiable transaction, a user agent must enable a
- session only if a cookie with a domain attribute D was sent or
- received in its origin transaction, such that the host name in the
- Request-URI of the unverifiable transaction domain-matches D.
+
+ When it makes an unverifiable transaction, a user agent MUST disable
+ all cookie processing (i.e., MUST NOT send cookies, and MUST NOT
+ accept any received cookies) if the transaction is to a third-party
+ host.
This restriction prevents a malicious service author from using
unverifiable transactions to induce a user agent to start or continue
a session with a server in a different domain. The starting or
continuation of such sessions could be contrary to the privacy
expectations of the user, and could also be a security problem.
- User agents may offer configurable options that allow the user agent,
+ User agents MAY offer configurable options that allow the user agent,
or any autonomous programs that the user agent executes, to ignore
the above rule, so long as these override options default to "off".
+ (N.B. Mechanisms may be proposed that will automate overriding the
+ third-party restrictions under controlled conditions.)
+
Many current user agents already provide a review option that would
render many links verifiable. For instance, some user agents display
the URL that would be referenced for a particular link when the mouse
pointer is placed over that link. The user can therefore determine
whether to visit that site before causing the browser to do so.
(Though not implemented on current user agents, a similar technique
could be used for a button used to submit a form -- the user agent
could display the action to be taken if the user were to select that
button.) However, even this would not make all links verifiable; for
example, links to automatically loaded images would not normally be
subject to "mouse pointer" verification.
Many user agents also provide the option for a user to view the HTML
source of a document, or to save the source to an external file where
it can be viewed by another application. While such an option does
provide a crude review mechanism, some users might not consider it
acceptable for this purpose.