- From: David W. Morris <dwm@xpasc.com>
- Date: Sun, 13 Jul 1997 17:51:25 -0700 (PDT)
- To: http-wg@cuckoo.hpl.hp.com
I have a number of remaining concerns with the HTTP State Management
Mechanism draft-02. They range from editorial and clarity to
functional. I'll sumarize the functional concerns and then step
thru the draft with detailed comments and/or suggestions.
Functional Concerns:
1. The cookie/cookie2 interoperational requirement that clients
clients merge the values from two cookie/cookie2 and servers
split the values present unnecessary implementation complexity
and opportunity for errors to conver a transition interval
and to save small amount of network traffic. More below.
2. I see no advantage to requiring the use of a FQHN in all
cases. It is sufficient to exactly match the host name
between URL's response which set the cookie and the URL
candidate for inclusion of the cookie. Intranet applications
work quite nicely with host names which are not FQHNs.
Furthermore, in the intranet context this has the potential
of requiring a user to type a FQHN to access an application
which uses Cookies. An unnecessary restriction. We
have already concluded in discussions relationg to 2068
and the Host: header that it is impossible to require a UA
to expand a simple host name into a FQHN.
3. Requiring the leading period in the domain= value can be
avoided by simply requiring that the client add the period
if it isn't provided prior to performing the domain matching.
4. There was a significant amount of interest/support for the
CommentURL as a better mechanism for communication between
the server and the user.
Dave Morris ---------------------->
Proposed changes and additional comments:
:: 2. Terminology
[...]
:: 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete this phrase
[...]
:: Host names can be specified either as an IP address or a FQHN string.
Replace the above line with:
Host names can be specified in any form acceptable to the base
HTTP protocol. That may be an IP address, an incomplete host name
string, or a FQHN string which is the prefered form.
:: Sometimes we compare one host name with another. Host A's name domain-
:: matches host B's if
Replace the following two points:
:: * both host names are IP addresses and their host name strings
:: match exactly; or
:: * both host names are FQDN strings and their host name strings
:: match exactly; or
with:
* both host name strings match exactly (this applies to IP
addresses and host name strings which are not FQHNs).
:: * 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.)
[...]
:: 3. STATE AND SESSIONS
[...]
:: 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:
::
:: 1. Each session has a beginning and an end.
::
:: 2. Each session is relatively short-lived.
::
:: 3. Either the user agent or the origin server may terminate a
:: session.
::
:: 4. The session is implicit in the exchange of state information.
I believe the above paragraphis is an unnecessary elaboration and
furthermore points 1 and 2 are incorrect. Point 2 is in
conflict with examples later in the document when storage of
preferences is discussed. If something like this paragraph remains,
points 1 and two should be more like:
1. Each session as an explicit beginning and an end which
can be approximated based on time and/or user termination
of user agent execution.
2. A cookie based session last over the interval appropriate
to the context established by the session.
[...]
:: 4.2.2 Set-Cookie2 Syntax
An earlier comment was made about quotes in the "Port" attribute,
but I think there are additional problems with the syntax as
specified and suggest that:
:: | "Port" [ "=" <"> 1#port-list <"> ]
:: port-list | 1#DIGIT
be replaced with:
| "Port" [ "=" portnum | <"> 1#portnum <"> ]
portnum = 1*DIGIT
If I correctly understand RFC2068 syntax, 1#X means 1 or more
occurances of X delimited by commas. My changes fix the "="
in port-list, the 1#DIGIT in port list and make the quotes
optional for the single port case.
To support the CommentURL, add:
| "CommentURL" "=" <"> http_URL <">
[...]
[...]
I think the issue is not so much that a cookie can contain private
information as it can be used to derive private information. Thus
I think the following:
:: Comment=comment
:: Optional. Because cookies can contain private information about a
:: user, the Comment attribute allows an origin server to document how
:: it intends to use the cookie. The user can inspect the information
should be changed to read something like:
Optional. Because cookies can be used to derive or store
private information about a user, the Comment attribute allows an
origin server to document how it intends to use the cookie. ...
and also to support the CommentURL in the description section, add:
CommentURL
Optional. Because cookies can be used to derive or store
private information about a user, the CommentURL
attribute alows 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.
[...]
:: Domain=domain
:: Optional. The Domain attribute specifies the domain for which the
:: cookie is valid. An explicitly specified domain must always start
:: with a dot.
Change the 'must' in the last sentence to 'should' and add:
If the domain does not start with a dot, the client MUST prepend
the dot logically prior to use of the domain value.
[...]
:: 4.2.3 Controlling Caching
[...]
:: 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
:: upstream HTTP/1.0 proxies. HTTP/1.1 servers may send other Cache-
^^^^ insert:
or that any upstream proxies will not cache the response.
:: 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.
For example, is it has been fairly well accepted that HTTP/1.0
proxies will not cache responses to POST requests or requests which
include a '?' part.
[...]
:: 4.3 User Agent Role
:: Port The default behavior is that a cookie may be returned only to
:: its request-port.
I think the correct default for Port is:
Port If the Port attribute is not specified, there are no
port restrictions for subsequent use of the cookie. If the
Port attribute is specified without a value, the cookie
may only be sent in a request to the same port that it
was received on.
[...]
:: 4.3.2 Rejecting Cookies
[...]
:: * The value for the Domain attribute contains no embedded dots
:: or does not start with a dot.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ delete the phrase
:: * A Set-Cookie2 with Domain=ajax.com will be rejected because the
:: value for Domain does not begin with a dot.
The above example should be deleted or replace with something like:
* A Set-Cookie2 with Domain=ajax.com will have a dot prepended
to value for Domain because it does not begin with a dot.
[...]
:: 4.3.3 Cookie Management If a user agent receives a Set-Cookie2
:: response header whose NAME is the same as a pre-existing cookie, and
^^ insert 'value with a cookie'
:: whose Domain and Path attribute values exactly (string) match those
A single set-cookie2 response header can contain multiple cookies.
[...]
:: 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.
^^ insert 'or size'
:: 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
^^^ or
:: inspection user interface.
The critical issue is that the Comment be made available to the user.
With the 'and' included, the specification makes an unnecessary
implementation restriction. How it is stored is not important unless
poking around in the storage area is the only mechanism the user
has for examination of the cookie.
To support CommentURL, the following should be added:
If a Set-Cookie2 response header includes a CommentURL attribute,
the user agent should either store the value in a human-readable
form with the cookie or preferably allow the user to link to the
URL as part of a cookie inspection interface.
:: 4.3.4 Sending Cookies to the Origin Server
[...]
:: 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 any, 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 any,
:: of the corresponding Set-Cookie2 response header. Otherwise the
:: attribute should be omitted from the Cookie request header.
I read the above to make sending of the $path and $domain values
on a cookie: response header as optional. To me it says, if the
$path and $domain values are sent, then be the values in the
set-cookie2 response header. Is this what is intended? Based on
later examples, I would have expected it be required that they
be returned if set.
[...]
:: 2. If the attribute is present but has no value (e.g., Port),
:: the cookie must only be sent to its request-port.
^^^^^^^^^^^^^^^^^
would be clearer I think if replaced with:
"the request-port it was received from.
4.3.5 Sending Cookies in Unverifiable Transactions
[...]
:: However, even this would not make all links verifiable; for example,
:: links to automatically loaded images would not normally be subject to
^^^ insert "or other objects
such as frame
content"
:: ``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.
That is the understatement of the year .... I would prefer words like
"many users would"
:: 4.5 Caching Proxy Role
[...]
:: Proxies must not introduce Set-Cookie2 (Cookie) headers of their own
^^^^ I would prefer 'should'
:: in proxy responses (requests).
:: 5. Examples
It looks to me like the exmaples are WRONG ... the syntax requires
the version prior to the cookie name/value. (This also implies
the historical rules for merging cookie and cookie2 are wrong).
:: 6. IMPLEMENTATION CONSIDERATIONS
[...]
:: 6.1 Set-Cookies Content
[...]
:: The session information can obviously be clear or encoded text that
:: describes state. However, if it grows too large, it can become
:: unwieldy. Therefore, an implementor might choose for the session
:: information to be a key to a server-side resource.
The above is fine and sufficient. The following comment asserts
a motivations for this specification which has not been established
and which I would disagree with. Delete the following ....
:: Of course, using
:: a database creates some problems that this state management
:: specification was meant to avoid, namely:
::
:: 1. keeping real state on the server side;
::
:: 2. how and when to garbage-collect the database entry, in case the
:: user agent terminates the session by, for example, exiting.
[...]
:: 6.3 Implementation Limits
[...]
Either delete the following completely or replace it. Dictating
that such a device dedicate 80K+ of storage to cookies is not
reasonable.
:: User agents created for specific purposes or for limited-capacity
:: devices should provide at least 20 cookies of 4096 bytes, to ensure
:: that the user can interact with a session-based origin server.
Calling something a limited capacity device, we have acknowledged
that we don't know its capabilities or its intended audience. I
don't advocate the following but could tolerate it if we are
compelled to say anything:
User agents created for specific purposes or for limited-capacity
devices should provide sufficient cookie storage capacity to
address the requirements of the applications they are intended
to serve.
[...]
:: 7.1 User Agent Control
[...]
The following is implementation advice which can be dropped. Surely
we need not instruct UA authors about data integrity.
:: 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.
[...]
:: 10. HISTORICAL
:: 10.1 Compatibility with Existing Implementations
As I stated in my introduction, I feel quite strongly that the
proposed handling of old and new cookies is wrong. I shall attempt
to proposed edits which will make this section fit my
recommendations.
[...]
Rewrite:
:: An origin server that supports user agents that are compatible both
:: with Netscape's original proposal and this one must, for a transition
:: period, send two response headers. Set-Cookie contains the ``old''
:: cookie information.
:: Set-Cookie2 contains the cookie information that
:: is new to this specification. The rules below ensure that the two
:: pieces get combined correctly.
:: Eventually, when the majority of user
:: agents follow this specification, the Set-Cookie response header can
:: be phased out, and all cookie information can be carried in the
:: Set-Cookie2 response header.
by replacing the broken out middle section with
Set-Cookie2 contains the the same cookie
information expressed according to this specification.
Then replace:
:: Once a server receives a new cookie from a client, it may continue a
:: session by sending only Set-Cookie2 response headers.
with:
New version of user agents which had previously stored cookies
based on Netscape's original specifications should convert
existing cookies by adding the $Version attribute with a value
of 0 to signal to the server the ability to handle Set-cookie2
format cookies.
Once a session is initiated during the transition period using
both set cookie headers in the first response to a user-agent
the server will know from the cookie header received in the
next request which form of cookies the user agent supports.
The server should only send either the Set-cookie2 if it is
supported or the set-cookie if Set-cookie2 is not supported on
subsequent responses which require an updated cookie value.
Then delete sections "10.1.1 Combining Set-Cookie and Set-cookie2"
and "10.1.2 An Example".
Received on Sunday, 13 July 1997 17:54:37 UTC