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

Re: Handling Client-Side Cookies

From: John Philip Anderson <jpanderson_215@hotmail.com>
Date: Tue, 12 Dec 2000 23:51:23 -0000
To: cwturner@cycom.co.uk
Cc: www-jigsaw@w3.org
Message-ID: <F240mRBaYFkuutSgcOr00007e49@hotmail.com>
Dear Mr. Christopher William Turner:

I must apologize.  You were absolutely CORRECT in your statement:

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

My statement:

    something(++i);
    something(i); i++;
    ...are logically equivalent

is FALSE.

At this point, I do not understand why my supposed "something(i); i++;" 
fixes appeared to have had an affect on my operation of Client-Side Jigsaw 
in my Microsoft environment.

However, I stand behind my comments regarding (Bug#1), (Bug#5) and "tail 
matching."

Truly yours,
John Philip Anderson




>From: "John Philip Anderson" <jpanderson_215@hotmail.com>
>To: cwturner@cycom.co.uk
>CC: www-jigsaw@w3.org
>Subject: Re: Handling Client-Side Cookies
>Date: Tue, 12 Dec 2000 23:11:08 -0000
>
>Dear Mr. Christopher William Turner,
>
>	Thank you for responding to my "Handling Client-Side Cookies" postings.  I
>sincerely appreciate your feedback.  First, I must unfortunately concede
>that I am indeed operating under one of those sketchy Microsoft
>environments, specifically Windows 98.
>
>	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, available 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, I believe that your statement:
>
>	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 position 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" nomenclature.  For example both of these
>statements :
>
>	something(++i);
>	something(i); i++;
>
>are logically equivalent.
>
>	Next, I want to respond 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, 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 interfere with any servers not called "www"
>(provided that they fully identify themselves in the "domain" field of any
>Set-Cookies headers that they generate).
>
>	Furthermore, if one examines the details of Client-Side "tail matching," 
>as
>described under "Syntax of the Set-Cookie Http Response Header" in the
>Netscape Cookie Specfiications
>(http://www.netscape.com/newsref/std/cookie_spec.html), the issue of "www"
>versus "w3" (or anything else) should be recognized as irrelevant on the
>Client-Side.
>
>	"Tail matching" is the selection of Request cookies on the basis of
>apparently only the last two domain "parts."  For example, Client-Side
>Jigsaw is only supposed to look for the parts "netscape" and "com" when
>searching the DomainTree for cookies to add to a Request going to
>"foo.bar.netscape.com", the "foo" and "bar" parts are not supposed to be
>considered part the of the "domain."
>
>	Again Chris, I want to thank you for your feedback.  Preparing this
>response has been good exercise for me.  Finally, if do I encounter any
>serious "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
>
>	jpanderson_215@hotmail.com
>
>
>>From: Christopher William Turner <cwturner@cycom.co.uk>
>>To: John Philip Anderson <jpanderson_215@hotmail.com>
>>CC: www-jigsaw@w3.org
>>Subject: Re: Handling Client-Side Cookies
>>Date: Tue, 12 Dec 2000 14:40:39 +0000
>>
>>John,
>>Your bugs of the form
>>
>>replace something(i++)
>>with something(i); i++;
>>
>>must be bugs in your compiler, jit or debugger since the
>>source code forms are equivalent according to the java spec.
>>(do you have a Microsoft component somewhere in your environment? :-))
>>Your changes are OK and may make it easier to watch variables in the
>>debugger.
>>
>>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 have web servers which are not called "www".
>>
>
>_____________________________________________________________________________________
>Get more from the Web.  FREE MSN Explorer download : 
>http://explorer.msn.com
>

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com
Received on Tuesday, 12 December 2000 18:52:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:34 GMT