- From: David W. Morris <dwm@aimnet.com>
- Date: Mon, 14 Jul 1997 23:27:18 -0700 (PDT)
- To: Dave Kristol <dmk@bell-labs.com>
- Cc: http-wg@cuckoo.hpl.hp.com
On Sun, 13 Jul 1997, Dave Kristol wrote:
> David W. Morris wrote:
> >
> > 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.
>
> [I'm still on vacation, so I'll do my best to respond. Please attribute
> stupid remarks from me to my brain's not being fully engaged. :-) ]
>
> >
> > 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.
>
> I think we've been through this discussion before, and we've rejected
> the alternatives
Well, there merge rules must be new since 2109 since the requirement stems
from the change to cookie2. When I reviewed the earlier draft and
objected to the rules, I recall two responses, one which supported my
position and one which indirectly blamed the requirement on a large
network service which felt the overhead would be too great. The parent
company has since made it quite clear that they have no intent of
supporting cookie2 proposal so their objection would seem moot. In any
case I have a real hard time accepting the overhead argument since the
duplicate is only required on the first encounter with a client and
perhaps not even then if the server site cares enough about overhead
to check the UserAgent string as has become tradition and in fact is
well supported by Microsoft's ASP support for sites which use IIS or PWS.
> >
> > 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
>
> FWIW, didn't Netscape's original spec. require FQHN?
Don't recall, but in practice the implementations don't require FQHN.
ZooWorks uses cookies quite nicely with NSNav 2, 3, & 4 and IE 2, 3 and
usually uses just 'zooworks' as the host name.
>
> Would you accept the case where the host name was a single unqualified
> word (no dots)? If so, I'll see if I can work that through the
> wording. But the assumption that would follow is that the cookie could
> return *only* to that host, not to related ones.
My argument, and my re-wording of the rules below, is that the FQHN
is not required and will only return to the origin host. There is no
point in asserting the no dot rule.
I really don't like unnecessary restrictions.
>
> > 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
>
> I think the reality is that most cookie-bearing applications get entered
> by following a link, and I don't think it's unreasonable for the link to
> have a FQHN.
Not if the application is entered from a bookmark for an Intranet
application which never used a FQHN. If all web pages in the site use
relative links and the user starts with something like:
http://mint/myap.asp
the FQHN will never exist.
>
> > 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.
>
> And I wouldn't expect a UA to expand one here, either.
Not true, you demand it. Otherwise, the UA is in violation of this
specification or can't support cookies.
> >
> > 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.
>
> Not so. I've discussed this several times before (although possibly
> privately). The no-dot form of the value (which is specifically not
> permitted by the spec., but which is the default if Domain= is omitted)
> restricts a cookie to return to just the origin server. The with-dot
> form permits returning the cookie to more than one server. (All the
> ones that domain-match the value.)
If the domain= value is specified and doesn't include the dot, the simple
fix is for the UA to add the dot ... this is a different situation from
the domain= attribute defaulting to the source host. Hence the domain
matching rules still hold.
> >
> > 4. There was a significant amount of interest/support for the
> > CommentURL as a better mechanism for communication between
> > the server and the user.
>
> My take on the discussion was that the opinions were mixed. Granted
> there is merit in the proposal, there are also concerns. You would have
> to establish rules about cookies in CommentURL, etc.
>
> I would like to table CommentURL to a followup to (the followup to) RFC
> 2109. (I made no further comments about your CommentURL remarks here.)
>
> >
> > 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
>
> No. The domain-matching rules and everything that flows from them
> depends on FQHN's. But I'll consider what I mentioned above, namely the
> case where request-host is a single word (no dots), and I would try to
> change the words accordingly.
Not true ... with the change I made below, the domain matching rules don't
depend on FQHNs and I can't see any possible breach of the intended
restrictions in terms of cookie sharing. In any case, there is absolutely
no way for a UA to know if a host name which includes a dot is a FQHN or
not. The domain matching and reach definition work just fine with
any three level name or an absolute match for a single host.
>
> > [...]
> >
> > :: 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.
>
> No again. See above.
My statement stands. The above fits the existing and expected RFC 2068/+.
Domain matching for support of multiple sites requires FQHNs and I
don't propose changing that requirement. Nor do I propose changing the
definition of FQHNs. My objection is for basic single host support, this
specification makes an unnecessary restriction.
>
> >
> > :: 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).
>
> Maybe, depending on your response to my question above.
While my immediate concern is resolved by a simple name, I can see no
reason to restrict this comparison to simple dot-less names. Hence,
simplicty should be the objective.
>
> >
> > :: * 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.
>
> I see your point. Let me think about it.
>
> >
> > [...]
> >
> > :: 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.
>
> Given that Port is new, I see no value, and potential risk, in making
> the quotes optional. The risk is that someone will forget them when
> there's a list.
>
> And I guess I don't understand what you want to "fix" about "=". Except
> for your allowing a single portnum to omit the quotes, your syntax and
> mine appear equivalent.
No, you have a "|" where there should be an equal sign and 1#DIGIT means
1,2,3 not 123 does it not?
>
> >
> > 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
>
> Surely both are true, depending on your definition of "private". For
> example, your username and password at some service (e.g., New York
> Times) is supposed to be private, but the service will, with your
> permission, put them in a cookie.
My point which in the tome might have been missed is that cookies will
often NOT contain any private information directly. The major discussion
has centered around what a site can learn by using cookies to track
user behavior, etc. I don't deny that they can contain explictly
private data (but so can hidden fields in a form, visable fields, etc.)
but think that it is important to mention the information gathering
exposure as at least an important motivation for our restrictions as
the actual possiblity of private content.
>
> > 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.
>
> That's only true, of course, if the UA allows you to do so.
That's true for both Comment and CommentURL.
>
> > [...]
> >
> > :: 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.
>
> No. (See above.)
Yes, ... this is one of those be tolerant about what you receive issues.
If the attribute is provided, which is what is discussed in the origina
text ("explictily specified ...") can easily be fixed by the client.
>
> > [...]
> >
> > :: 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.
>
> The problem with that is those rules are heuristics that have been
> implemented by some proxies. They are not mandated by any (HTTP/1.0)
> spec., so you can't depend on them. All you really (might) know is
> their HTTP version number. As a practical matter I think it's unlikely
> for an originserver to know there are no upstream proxies, and it will
> have to send Expires anyway.
As a practical matter, the key is 'out of band' and it applies not to
the existance of a flavor of proxy but to whether caching will occur.
Browsers screw up their history lists bad enough w/o expires being
added to what they see. With my words the implementor who bothers to
read has been alterted to the controlling caching issues and must make
a judgement call. For example, if the cookie only carries a session-id
which must also be synchronized with an IP address to be valid, there is
little risk if the wrong user receives the cookie.
>
> >
> > [...]
> > :: 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.
>
> No. I believe I wrote what was the consensus of the comments about Port
> when it was first discussed. Furthermore, I asked for concurrence on
> the words when I first issued an I-D that describe Port, and I got it
> (through an absence of objections).
Please re-read my words ... basically I just made this statement match
the later words in the document about Port. There are three states:
No attribute; Port w/o a number; and port with numbers.
The existing draft words here and later don't agree. See starting at
line 606 in the draft discussing port selection.
>
> > [...]
> >
> > :: 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.
>
> No. That would mean something different. See above.
Well, in the end we either agree that my proposal that the UA fix up
a bad domain= value or not. I tried to cover all required edits to make
the document match up. If after my latest comments no-one else cares and
you still disagree, I don't consider this a very big deal just a nit where
we could tolerate poor coding to no harm done.
> >
> > [...]
> > :: 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
>
> I sort of see what you're trying to say (especially given your next
> comment), but I don't think the words are necessary. A Set-Cookie2
> logically takes a single NAME, even though multiple Set-Cookie2's could
> be folded together.
I suppose.
> >
> > A single set-cookie2 response header can contain multiple cookies.
>
> Redundant. It's implied by RFC 822 header folding.
>
> >
> > [...]
> > :: 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.
>
> I take your point. However, the second part is a "should", and what
> constitutes a "cookie inspection user interface" is intentionally
> unspecified so as not to "[make] an unnecessary implementation
> restriction". If we make this an "or", a UA could (as some already do)
> bury the cookie in some obscure place where it's hard for a user to
> find.
My intent was that they either provide a cookie inspection interface OR
make it human readible. As written the draft requires it be human
readible, not human findable.
>
> >
> > 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.
>
> I'll have to clarify that. What's meant is that if the UA receives
> those attributes, it must return them. If it uses the defaults because
> they were omitted in Set-Cookie[2], it should not return them. The idea
> is for the server to get reflected back to it what it sent to the UA.
That is what I figured you meant. I think that is the better alternative.
> >
> > [...]
> >
> > :: 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.
>
> Okay.
>
> >
> > 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"
>
> Unfortunately, content magic is outrunning the speed with which we can
> get out the spec. :-) I think (hope) that just mentioning images gets
> the point across. Otherwise it begins to look like we're trying to give
> an exhaustive list of unverifiable transactions, which is impossible.
I agree about the exhaustive concern, but frames are such an obvious
place for abuse I thougt it might be worth mentioning them but then I'm
a lot less concerned overall about potential abuse so I don't care.
>
> > :: ``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).
>
> Given that cookies are an end-to-end mechanism and controlled by an
> origin server (supposedly), it's hard for me to imagine a valid case
> where a proxy could introduce a Set-Cookie2. Now proxy cookies are
> another matter....
Well I once wrote a long explanation about how a very clever proxy
might be able to combine cookies with an extended authentication scheme
by tacking an ID set-cookie on every response. Don't know how good
an idea it was of if it would work but on the principal that I
could see no harm in having a proxy do something with cookies, I figured
that should was a strong enough restriction.
> >
> > :: 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).
>
> I don't think so. (Granted I only made a quick scan of the examples.)
> The Version attribute in Set-Cookie[2] can be in any order after
> NAME=VALUE. $Version must be first in the Cookie header. I think the
> examples consistently do that. And I think the cookie merging rules
> work.
Hmmm... perhaps it was my bleary eyes and reading set-cookieX as cookie.
The merging examples seem to assume version= as the last av pair and
perhaps that is the precise intent of the syntax but I didn't see it
stated anywhere and it is generally traditional when av kinds of pairs
have names that order may not be significant. I certainly don't read
an order requirement into the diagrams ... but I could be wrong on that
one. Anyway now I don't see a problem with the $version positioning.
Sorry.
>
> >
> > :: 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.
>
> They're only implementation *considerations*. Would you claim that 1
> and 2 are false? We're pointing out the trade-off: you can either have
> complete state sent back and forth between origin server and UA, or you
> can pass a handle back and forth. But if you do the latter, there are
> other considerations that come into play. Doing the former, where
> possible, seems easier to me.
Well, its hard for me to know everyone's motivations for this
specification but I consider it bad design to pass bunches of stuff
back and forth ... performance, security implications, etc.
If you want to get into implemenation considerations, there are is a log
more that could be said.
My objection isn't really to statements 1 and 2 but rather the
declaration of intent for the specification. If you feel a need to say
more than something like:
Of course, using a database introduces the problem of how to manage
the persistence of server side state information.
Having written or designed multiple applications before and since cookies
which used the handle approach, I don't see it as a very big deal.
I see the motivation as being elimination of munged URLs and hidden form
data as being the primary motivation for this specification.
For example, with ASP on Microsoft IIS and PWS, complete provisions
are builtin for managing server side state, timing it out, etc.
> >
> > [...]
> > :: 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.
>
> I see your point, and I guess that's okay. The purpose of the section
> was to set out some bounds so (unrelated) origin servers and UAs would
> be able to depend on certain minima. I grant that special-purpose
> agents tailored to a single application can cut things closer to the
> bone. But of course the "should" already lets them do so.
>
> >
> > [...]
> > :: 7.1 User Agent Control
> > [...]
> >
> > The following is implementation advice which can be dropped. Surely
> > we need not instruct UA authors about data integrity.
>
> I suppose, but it doesn't hurt anything.
>
> >
> > :: 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.
>
> You lost me. Which recommendations? Oh, you mean to send complete
> Set-Cookie and Set-Cookie2. No, we've chosen not to do that.
Which choice I don't accept.
>
> > [...]
> > 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.
>
> Sorry, but that proposal was considered and rejected many months ago.
In the only discussion I saw on this list it was two for and 1 negative
expressed represting a third party I never saw speak on the issue.
> >
> > 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".
Dave Morris
Received on Monday, 14 July 1997 23:32:49 UTC