W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

RE: State Management pre-draft - combinational requirement

From: Yaron Goland <yarong@microsoft.com>
Date: Thu, 7 Aug 1997 14:18:54 -0700
Message-Id: <11352BDEEB92CF119F3F00805F14F4850354E15B@RED-44-MSG.dns.microsoft.com>
To: 'Foteos Macrides' <MACRIDES@sci.wfbr.edu>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-state@lists.research.bell-labs.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4112
I really must object to the statement that IE has "parsing problems"
with cookies. IE's implementation is consistent with the documentation
for cookies released by Netscape. It happens that David Kristol decided
to rely upon an undocumented feature in Netscape's implementation in
order to maintain backwards compatibility. As often happens with
undocumented features, Microsoft did not implement the feature the same
way. The reason RFC 2108 will be replaced is not because IE did anything
wrong, it is because David did not investigate why it was that his new
spec failed with IE.

As for combinatorial vs additive, I wonder as to the utility of the
current cookie spec. Given the realities of future implementations it
would seem more reasonable to write a solid specification of the current
cookie mechanism and leave the matter there.


> -----Original Message-----
> From:	Foteos Macrides [SMTP:MACRIDES@sci.wfbr.edu]
> Sent:	Saturday, July 26, 1997 2:37 PM
> To:	http-wg@cuckoo.hpl.hp.com;
> http-state@lists.research.bell-labs.com
> Subject:	State Management pre-draft - combinational requirement
> requirement in the latest State Management pre-draft.
> 	The current effort at a revision of RFC 2108 began when Koen
> pointed out that use of version 1 cookie attributes as in the RFC's
> specifications for modern Set-Cookie headers are not handled
> adequately
> by MSIE's implementation for historical cookies.  We all promptly
> agreed
> that a revision to ensure backward compatibility with that old
> implementation
> is important.  In the process of discussing a revision, it also was
> brought
> out that the blanket port restriction has the side effect of blocking
> any
> cookie sharing between http and https servers, even when such sharing
> should
> not be blocked.  The desireablility of a discard attribute promptly
> reached
> consensus, and of a commentURL attribute to accommodate i18n concerns
> beyond
> the too meagre comment attribute is being discussed.  The new
> attributes
> (port, discard and commentURL) all could be incorporated in a simple
> and
> elegant manner as extensions to the RFC 2108 Set-Cookie header, but to
> accommodate MSIE's parsing problems with that, we decided to create a
> separate, Set-Cookie2 header for modern cookies.  The issue of how
> this
> affects UAs which implemented RFC 2108 (e.g., Lynx in its v2.7 and
> v2.7.1
> formal releases), i.e., if Set-Cookie headers regressed to historical,
> was
> not a factor in these discussions.  Though in principle this is to be
> a
> revision based implementation experience, it has proceded largely as
> if
> there were none, and as if backward compatibility with RFC 2018 is not
> a
> consideration (that's OK, don't worry about it :).
> 	Then we received a complaint that having Set-Cookie2 headers for
> modern cookies and duplicates in Set-Cookie headers for historical UAs
> is a "problem" for an organization which makes a practice of setting
> large
> numbers of lengthy cookies, so the combinational requirement was born.
> To get an idea of that "problem", try http://www.microsoft.com/ with a
> clean cookie jar.  You will be sent through a series of redirections,
> and
> cookie replacements, with the ultimate result of your cookie jar
> acquiring
> two seemingly identical cookies for hosts which don't domain match
> according
> either to RFC 2108 or the current pre-draft.  When I tried today,
> after the
> multiple redirections and replacements abated, I ended up with the
> cookies
> of identical name and value:
> 	Domain=.msn.com
> 	       ||||||||
> 	MC1=GUID=5e1a543305d611d188a708002bb74f65
> 	Domain=.microsoft.com
> 	       ||||||||||||||
> 	MC1=GUID=5e1a543305d611d188a708002bb74f65
> I don't know if those should be considered "long" cookie name/value
> pairs,
> and can only image what might be accomplished if private discussions
> led
> to the maximum of 5 redirections becoming a minimum, and my UA could
> be
> looped through 100 redirections.  Nor am I clear on why the ability to
> load users' often limited resources with large numbers of lenthy, and
> perhaps redundant, cookies should be promoted by the IETF.
> 	The objections that were posted about the combinational
> requirement
> merit more careful consideration, IMHO.  The intent originally was to
> send
> both Set-Cookie2 and Set-Cookie headers during a *transitional* period
> to
> the modern State Management design,  This is essentially a "probing" 
> situation, and as soon as either the UA or server detects that modern
> cookie support is implemented in its State Management partner, only
> Set-Cookie2 headers will be sent to the UA by the server's replies,
> and
> the modern Cookie header format will be used in the UAs requests to
> the
> server.  The sending of both Set-Cookie2 and Set-Cookie header thus
> will become limited to just "first contacts", which are not likely to
> involve large numbers of cookies (except, perhaps in lengthy
> redirection
> and cookie replacement loops :).
> 	The principle objection to the combinational requirement is that
> it makes the protocol excessively complex and correspondingly
> unreliable,
> such that it in fact serves to discourage, rather than promote, the
> implementation of a modern State Management design geared toward more
> nearly adequate protection of users' privacy.   The section on
> combining
> Set-Cookie and Set-Cookie2 headers (10) says:
>   [...]                                           The user agent
>                                                       ^^^^^^^^^^
>   interprets the combined headers as follows.  First, it must
> establish a
> ||||^^^^^^^^^^^^
>   one-to-one correspondence between the cookies in the Set-Cookie and
>   ||||||||||^^^^^^^^^^^^^^^
> Set-Cookie2 headers. [...]
> How can the UA establish that *one-to-one* correspondence?  The cookie
> name/value pairs will all be in the Set-Cookie header, and the
> Set-Cookie2
> header will have only additional attributes.  The ONLY correspondence
> check
> which a UA can perform is to count the number of version 1 attribute
> sets
> folding into a Set-Cookie2 array, and compare that with the number of
> historical cookies folded into a Set-Cookie array.  If the two counts
> are not the same, e.g., due to some semi-colon verus comma
> substitution,
> or any number of possible network transmission glitches, there is NO
> basis
> here for efforts at error recovery, or any efforts, whatsoever, for
> bona fide
> correspondence checks.  If the counts are different, for any reason,
> the
> UA will have no alternative but simply to throw the cookies and
> attributes
> on the floor and hope for better luck next time.
>         That section also points out, parenthetically:
>         (Note that in this case the Set-Cookie2 response header that
>          the origin server sends does not, by itself, conform to this
>                                  ||||||||^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>          specification.)
>          ^^^^^^^^^^^^^
> Think about that.  Is a "transitional" procedure for sending
> Set-Cookie2
> headers which DO NOT CONFORM TO THE SPECIFICATION a way to promote
> implementation of that specification, or a way to interfere with it's
> implementation?!?  Think about that carefully, please.
>         It is often the case in the real world that the squeeky wheel
> gets oiled first.  But if instead the wheels are being rearranged so
> that the wagon won't go anywhere, perhaps that is one case in which it
> it truly appropriate to just say no.
>                                 Fote
> ======================================================================
> ===
>  Foteos Macrides            Worcester Foundation for Biomedical
> Research
>  MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
> ======================================================================
> ===
Received on Thursday, 7 August 1997 14:20:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC