Apache-SecSess
view release on metacpan or search on metacpan
rfc/rfc2965.txt view on Meta::CPAN
3.2.2 Set-Cookie2 Syntax The syntax for the Set-Cookie2 response
header is
set-cookie = "Set-Cookie2:" cookies
cookies = 1#cookie
cookie = NAME "=" VALUE *(";" set-cookie-av)
NAME = attr
VALUE = value
set-cookie-av = "Comment" "=" value
| "CommentURL" "=" <"> http_URL <">
| "Discard"
| "Domain" "=" value
| "Max-Age" "=" value
| "Path" "=" value
| "Port" [ "=" <"> portlist <"> ]
| "Secure"
| "Version" "=" 1*DIGIT
portlist = 1#portnum
portnum = 1*DIGIT
Informally, the Set-Cookie2 response header comprises the token 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 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, the client SHALL use only the value associated with the first
appearance of the attribute; a client MUST ignore values after the
first.
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.
NAME=VALUE
REQUIRED. The name of the state information ("cookie") is NAME,
and its value is VALUE. NAMEs that begin with $ are reserved and
MUST NOT be used by applications.
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 Set-Cookie2
header.
Kristol & Montulli Standards Track [Page 5]
RFC 2965 HTTP State Management Mechanism October 2000
Comment=value
OPTIONAL. Because cookies can be used to derive or store private
information about a user, the value of the Comment attribute
allows an origin server to document 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. Characters in
value MUST be in UTF-8 encoding. [RFC2279]
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.
Discard
OPTIONAL. The Discard attribute instructs the user agent to
discard the cookie unconditionally when the user agent terminates.
Domain=value
OPTIONAL. The value of the Domain attribute specifies the domain
for which the cookie is valid. If an explicitly specified value
does not start with a dot, the user agent supplies a leading dot.
Max-Age=value
OPTIONAL. The value of the Max-Age attribute is delta-seconds,
the lifetime of the cookie in seconds, a decimal non-negative
integer. 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]. When the age is
greater than delta-seconds seconds, the client SHOULD discard the
cookie. A value of zero means the cookie SHOULD be discarded
immediately.
Path=value
OPTIONAL. The value of the Path attribute specifies the subset of
URLs on the origin server to which this cookie applies.
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.
Kristol & Montulli Standards Track [Page 6]
RFC 2965 HTTP State Management Mechanism October 2000
Secure
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, to protect the
confidentially and authenticity of the information in the cookie.
The user agent (possibly with user interaction) 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. 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.
Version=value
REQUIRED. The value of the Version attribute, a decimal integer,
rfc/rfc2965.txt view on Meta::CPAN
Examples:
* 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-Cookie2 from request-host x.foo.com for Domain=.foo.com
would be accepted.
* A Set-Cookie2 with Domain=.com or Domain=.com., will always be
rejected, because there is no embedded 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.
Kristol & Montulli Standards Track [Page 9]
RFC 2965 HTTP State Management Mechanism October 2000
* 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.
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,
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-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.
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;
Kristol & Montulli Standards Track [Page 10]
RFC 2965 HTTP State Management Mechanism October 2000
* 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.
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 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] [";" port]
cookie-version = "$Version" "=" value
NAME = attr
VALUE = value
rfc/rfc2965.txt view on Meta::CPAN
Applications should use as few and as small cookies as possible, and
they should cope gracefully with the loss of a cookie.
5.3.1 Denial of Service Attacks User agents MAY choose to set an
upper bound on the number of cookies to be stored from a given host
or domain name or on the size of the cookie information. Otherwise a
malicious server could attempt to flood a user agent with many
cookies, or large cookies, on successive responses, which would force
out cookies the user agent had received from other servers. However,
the minima specified above SHOULD still be supported.
6. PRIVACY
Informed consent should guide the design of systems that use cookies.
A user should be able to find out how a web site plans to use
information in a cookie and should be able to choose whether or not
those policies are acceptable. Both the user agent and the origin
server must assist informed consent.
Kristol & Montulli Standards Track [Page 19]
RFC 2965 HTTP State Management Mechanism October 2000
6.1 User Agent Control
An origin server could create a Set-Cookie2 header to track the path
of a user through the server. Users may object to this behavior as
an intrusive accumulation of information, even if their identity is
not evident. (Identity might become evident, for example, if a user
subsequently fills out a form that contains identifying information.)
This state management specification therefore requires that a user
agent give the user control over such a possible intrusion, although
the interface through which the user is given this control is left
unspecified. However, the control mechanisms provided SHALL at least
allow the user
* to completely disable the sending and saving of cookies.
* to determine whether a stateful session is in progress.
* to control the saving of a cookie on the basis of the cookie's
Domain attribute.
Such control could be provided, for example, by mechanisms
* to notify the user when the user agent is about to send a
cookie to the origin server, to offer the option not to begin a
session.
* to display a visual indication that a stateful session is in
progress.
* to let the user decide which cookies, if any, should be saved
when the user concludes a window or user agent session.
* to let the user examine and delete the contents of a cookie at
any time.
A user agent usually begins execution with no remembered state
information. It SHOULD be possible to configure a user agent never
to send Cookie headers, in which case it can never sustain state with
an origin server. (The user agent would then behave like one that is
unaware of how to handle Set-Cookie2 response headers.)
When the user agent terminates execution, it SHOULD let the user
discard all state information. Alternatively, the user agent MAY ask
the user whether state information should be retained; the default
should be "no". If the user chooses to retain state information, it
would be restored the next time the user agent runs.
Kristol & Montulli Standards Track [Page 20]
RFC 2965 HTTP State Management Mechanism October 2000
NOTE: User agents should probably be cautious about using files to
store cookies long-term. If a user runs more than one instance of
the user agent, the cookies could be commingled or otherwise
corrupted.
6.2 Origin Server Role
An origin server SHOULD promote informed consent by adding CommentURL
or Comment information to the cookies it sends. CommentURL is
preferred because of the opportunity to provide richer information in
a multiplicity of languages.
6.3 Clear Text
The information in the Set-Cookie2 and Cookie headers is unprotected.
As a consequence:
1. Any sensitive information that is conveyed in them is exposed
to intruders.
2. A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results.
These facts imply that information of a personal and/or financial
nature should only be sent over a secure channel. For less sensitive
information, or when the content of the header is a database key, an
origin server should be vigilant to prevent a bad Cookie value from
causing failures.
A user agent in a shared user environment poses a further risk.
Using a cookie inspection interface, User B could examine the
contents of cookies that were saved when User A used the machine.
7. SECURITY CONSIDERATIONS
( run in 0.918 second using v1.01-cache-2.11-cpan-ceb78f64989 )