Re: Handling Client-Side Cookies

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

Received on Tuesday, 12 December 2000 18:11:40 UTC