W3C home > Mailing lists > Public > www-jigsaw@w3.org > November to December 2000

Re: Handling Client-Side Cookies

From: <Anyway99@aol.com>
Date: Tue, 12 Dec 2000 16:30:59 -0500 (EST)
To: <cwturner@cycom.co.uk>
Cc: <www-jigsaw@w3.org>, <jpanderson_215@hotmail.com>
Message-ID: <32.dca679e.2767f140@aol.com>
Dear Mr Christopher William Turner,
    Thank you for responding to my "Handling Client-Side Cookies" postings.  I sincerely appreciate your feedback.
    First, I must unfortuantely concede that I am indeed operating under one of those sketchy Microsoft environments, specifically Windows 98 (at this moment, I can not even access my Microsoft owned Hotmail email account) .  

    However and with all due respect, I must argue with your other assertions.  So to begin, I cite: "Thinking in Java, 2nd Edition," (Bruce Eckel, Prentice-Hall, June 2000, availible FREE at http://www.bruceeckel.com) at Page 139:

    For pre-increment and pre-decrement, (i.e., ++a or --a), the operation is
    performed and the value is produced. For post-increment and post-decrement
    (i.e. a++ or a--), the value is produced, then the operation is performed.

Therefore,  your statement that: 

    replace something(i++) 
    with something(i); i++;
    ... are equivalent according to the java spec.
is false.

    This is the difference between the "pre-increment" (++i) and the "post-increment" (i++).  The "pre" and "post" refer to the postion of the "++" operator (not the sequence of operation).  Indeed, as described by Bruce Eckel above, the sequence of operation  is exactly opposite to the that implied by the "pre" and "post" nomanclature.  For example both of these statements :

    something(i); i++; 

are logically equivalent.  

    Next, I want to repond to your second statement:
    The insertion of a "www" probably hides a bug most of the time but a true fix is probably not to assume any     "www" as a host name. I for one, [I] have web servers which are not called "www". 

I agree with you in that what I have proposed may be considered more of "hack" than a "true fix."  However, my proposed solution, which is to insert to following line:
    if(parts[0].length() == 0) parts[0] = "www";
into the beginning of the Jigsaw DomainTree.insertCookies() method source code, does not directly interfer with any servers not called "www" (provided that they fully identify themselves in the "domain" field of any Set-Cookies headers that they generate). 

    However, while looking at the Netscape Cookie Specfiications (http://www.netscape.com/newsref/std/cookie_spec.html) I have become more concerned about this issue of Client-Side "tail matching," as desribed under the "Syntax of the Set-Cookie Http Response Header."  I suspect that you may be correct in this: even with the addition of my "hack," Client-Side Jigsaw still may have some kind of a bug in performing "tail matching."   ("Tail matching" is apparently the selection of Request cookies on the basis of only the last two domain "parts," that is only looking for "netscape" and "com" when searching the DomainTree for cookies to add to a Request for "foo.bar.netscape.com" .)

    Again Chris, I want to thank you for your feedback.  Preparing this response has been good exercise for me.  Finally, if I encounter any more "tail matching" problems in the near future,  I will be posting a "true fix" to replace the proposed "hack."

    Truly yours,
    John Philip Anderson
    Michigan, USA

Received on Tuesday, 12 December 2000 21:01:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:29 UTC