ASP cokies problem under i.e.

[patbaudy]

Hi,
I'm coding a shopping cart in asp. I store all info about ordered items,
customer's coordonates, etc...into cookies.
When the order is complete I use "CDONTS.NewMail" to send an order
confirmation's email, where all items and details are listed for the
customer.
As to retreive all these info a code reads all info stored in the cookies.
If a run my code under Firefox and Konqeror , all works well and the sent
email contains all info. But not under i.e!!!

So, I wrote a code to read all cookies on the page before opening the page
that generates the email to the customer, then when tested, all the cookies
and session variables can be read.
Under i.e., if the same code is run in the page generating the email, it
returns empty session variables and some cookies are missing or are now
empty or can't be read!!!
If it is tested under Firefox and Konqeror all cookies and session variable
are stil there!

Can someone help me?
Thank you.

 

[Stefan Berglund]

Hi,
I'm coding a shopping cart in asp. I store all info about ordered items,
customer's coordonates, etc...into cookies.
When the order is complete I use "CDONTS.NewMail" to send an order
confirmation's email, where all items and details are listed for the
customer.
As to retreive all these info a code reads all info stored in the cookies.
If a run my code under Firefox and Konqeror , all works well and the sent
email contains all info. But not under i.e!!!

So, I wrote a code to read all cookies on the page before opening the page
that generates the email to the customer, then when tested, all the cookies
and session variables can be read.
Under i.e., if the same code is run in the page generating the email, it
returns empty session variables and some cookies are missing or are now
empty or can't be read!!!
If it is tested under Firefox and Konqeror all cookies and session variable
are stil there!

Can someone help me?
Thank you.

This is probably more of a client side issue than an ASP issue and more
than likely not the cause of your specific problem but I'll throw this
out anyway. If you're doing anything with the year in computing your
expiration date for the cookies, the javascript getYear function returns
different values in Firefox than in IE. In Firefox you need to add 1900
to the value but not in IE. I believe that this is another case where
IE does not follow the spec and Firefox does.

var today=new Date();
var year=today.getYear()+1;
if(year<200) {year+=1900}
var expiryDate=new Date("December 31, " + year.toString() + "23:59:59");
SetCookie(escape(document.ShowSchedule.BillInfo.value),sDetail,expiryDate);

 

[Mark J. McGinty]

This is probably more of a client side issue than an ASP issue and more
than likely not the cause of your specific problem but I'll throw this
out anyway. If you're doing anything with the year in computing your
expiration date for the cookies, the javascript getYear function returns
different values in Firefox than in IE. In Firefox you need to add 1900
to the value but not in IE. I believe that this is another case where
IE does not follow the spec and Firefox does.

The getFullYear() function is supported uniformly by all of them, iirc, it's
the ECMA answer to the problem. Personally I have to wonder whether the
ECMA folks that decided this weren't gathering wild mushrooms without good
field guide! What on earth was their incentive to proliferate Y2K-style
issues. It'd likely be worth the minor amount of code the change would
break, just to be rid of it....

var today=new Date();
var year=today.getYear()+1;
if(year<200) {year+=1900}
var expiryDate=new Date("December 31, " + year.toString() + "23:59:59");
SetCookie(escape(document.ShowSchedule.BillInfo.value),sDetail,expiryDate);

Shouldn't the test be if (year < 1900)? Since 2-digit years arbitrarily
impute 1900 as the base -- and it's extremely unlikely that base will ever
change -- code that test year < 200 will cause problems in only 95 years.

Now you may be thinking, if they're still running this same code in 95
years, 2100 will be a sad year for IT... In other words, chances are poor it
would ever be an issue -- I tend to agree, however, that's exactly what they
were thinking in the 70's an 80's! History proved otherwise.

So the point is, why code something inaccurately, and in a way that has a
difinitively short-term finite life span, when it would be just as easy to
code it accurately?

-Mark

 

[Stefan Berglund]

On Sat, 28 May 2005 12:09:07 -0700, "Mark J. McGinty"

The getFullYear() function is supported uniformly by all of them, iirc, it's
the ECMA answer to the problem. Personally I have to wonder whether the
ECMA folks that decided this weren't gathering wild mushrooms without good
field guide! What on earth was their incentive to proliferate Y2K-style
issues. It'd likely be worth the minor amount of code the change would
break, just to be rid of it....



Shouldn't the test be if (year < 1900)? Since 2-digit years arbitrarily
impute 1900 as the base -- and it's extremely unlikely that base will ever
change -- code that test year < 200 will cause problems in only 95 years.

Now you may be thinking, if they're still running this same code in 95
years, 2100 will be a sad year for IT... In other words, chances are poor it
would ever be an issue -- I tend to agree, however, that's exactly what they
were thinking in the 70's an 80's! History proved otherwise.

So the point is, why code something inaccurately, and in a way that has a
difinitively short-term finite life span, when it would be just as easy to
code it accurately?

-Mark

Hey Mark,

Well, I can't argue with such a direct answer other than to say that why
don't you try the code in both browsers and then offer your solution.
Apparently, you've missed the issue here since it has nothing to do with
the Y2K issue and only to do with how the two javascript runtimes behave
with respect to the specified function (getYear).

And actually I do have a correction to make since I want my cookie to
expire on the last day of next year (effectively permanent if used each
year):

var today=new Date();
var year=today.getYear();
if(year<200) {year+=1900}
year+=1;
var expiryDate=new Date("December 31, " + year.toString() + "23:59:59");
SetCookie(escape(document.ShowSchedule.BillInfo.value),sDetail,expiryDate);

 

[Mark J. McGinty]

On Sat, 28 May 2005 12:09:07 -0700, "Mark J. McGinty"

in <[email protected]>
[snip]
var today=new Date();
var year=today.getYear()+1;
if(year<200) {year+=1900}
var expiryDate=new Date("December 31, " + year.toString() + "23:59:59");
SetCookie(escape(document.ShowSchedule.BillInfo.value),sDetail,expiryDate);

Shouldn't the test be if (year < 1900)? Since 2-digit years arbitrarily
impute 1900 as the base -- and it's extremely unlikely that base will ever
change -- code that test year < 200 will cause problems in only 95 years.

Now you may be thinking, if they're still running this same code in 95
years, 2100 will be a sad year for IT... In other words, chances are poor
it
would ever be an issue -- I tend to agree, however, that's exactly what
they
were thinking in the 70's an 80's! History proved otherwise.

So the point is, why code something inaccurately, and in a way that has a
difinitively short-term finite life span, when it would be just as easy to
code it accurately?

-Mark

Hey Mark,

Well, I can't argue with such a direct answer other than to say that why
don't you try the code in both browsers and then offer your solution.

Oddly enough, I have tried the code, in at least 4 browsers (IE, Opera,
Firefox and Netscape.) It works because the underlying logic is sound. Do
you have an argument or test case to refute this?

Apparently, you've missed the issue here since it has nothing to do with
the Y2K issue and only to do with how the two javascript runtimes behave
with respect to the specified function (getYear).

I didn't say *the* Y2K issue, I said "Y2K-style" issue, but obviously that
reference was too obscure, so to define, what I meant by that was a type of
software problem caused by code that makes false assumptions based on
2-digit year values, that will predictably fail after a given date.

Your code will predictably fail as of 01 January 2100, because the
assumptions that underlie your test of (yr < 200) are inaccurate, the value
200 is arbitrary and meaningless, it merely happens to work right now
because it's sufficiently high. Logically, that will not always be the
case.

The question in my mind was and is, why would someone choose to write code
like that? At least the desogners of ancient languages like COBOL and
FORTRAN had a compelling reason for their choice, 1KB of memory had to be
wheeled-in on a hand-truck. Even though that reason is very long gone,
implementations of that choice, and throw-backs thereto, persist to this
day.

But there's a difference here, getYear doesn't return a 2-digit year, it
returns the current year minus 1900, it actually does return complete data,
it's just in a denormal form. Early computer systems literally lacked part
of the data, their choices were limited, yours are not... so what's *your*
reason?

And I didn't miss the issue at all, I was merely pointing out that your
solution was flawed... and I see that it will continue to be flawed, by your
'correction' below -- very scientiffic approach, by all means stick with it,
what consequences could there possibly be? (Those who do not learn from
history are destined to repeat it.)


-Mark

 

[Stefan Berglund]

On Sun, 29 May 2005 12:35:53 -0700, "Mark J. McGinty"

On Sat, 28 May 2005 12:09:07 -0700, "Mark J. McGinty"

in <[email protected]>
[snip]
var today=new Date();
var year=today.getYear()+1;
if(year<200) {year+=1900}
var expiryDate=new Date("December 31, " + year.toString() + "23:59:59");
SetCookie(escape(document.ShowSchedule.BillInfo.value),sDetail,expiryDate);

Shouldn't the test be if (year < 1900)? Since 2-digit years arbitrarily
impute 1900 as the base -- and it's extremely unlikely that base will ever
change -- code that test year < 200 will cause problems in only 95 years.

Now you may be thinking, if they're still running this same code in 95
years, 2100 will be a sad year for IT... In other words, chances are poor
it
would ever be an issue -- I tend to agree, however, that's exactly what
they
were thinking in the 70's an 80's! History proved otherwise.

So the point is, why code something inaccurately, and in a way that has a
difinitively short-term finite life span, when it would be just as easy to
code it accurately?

-Mark

Hey Mark,

Well, I can't argue with such a direct answer other than to say that why
don't you try the code in both browsers and then offer your solution.

Oddly enough, I have tried the code, in at least 4 browsers (IE, Opera,
Firefox and Netscape.) It works because the underlying logic is sound. Do
you have an argument or test case to refute this?

Apparently, you've missed the issue here since it has nothing to do with
the Y2K issue and only to do with how the two javascript runtimes behave
with respect to the specified function (getYear).

I didn't say *the* Y2K issue, I said "Y2K-style" issue, but obviously that
reference was too obscure, so to define, what I meant by that was a type of
software problem caused by code that makes false assumptions based on
2-digit year values, that will predictably fail after a given date.

Your code will predictably fail as of 01 January 2100, because the
assumptions that underlie your test of (yr < 200) are inaccurate, the value
200 is arbitrary and meaningless, it merely happens to work right now
because it's sufficiently high. Logically, that will not always be the
case.

The question in my mind was and is, why would someone choose to write code
like that? At least the desogners of ancient languages like COBOL and
FORTRAN had a compelling reason for their choice, 1KB of memory had to be
wheeled-in on a hand-truck. Even though that reason is very long gone,
implementations of that choice, and throw-backs thereto, persist to this
day.

But there's a difference here, getYear doesn't return a 2-digit year, it
returns the current year minus 1900, it actually does return complete data,
it's just in a denormal form. Early computer systems literally lacked part
of the data, their choices were limited, yours are not... so what's *your*
reason?

And I didn't miss the issue at all, I was merely pointing out that your
solution was flawed... and I see that it will continue to be flawed, by your
'correction' below -- very scientiffic approach, by all means stick with it,
what consequences could there possibly be? (Those who do not learn from
history are destined to repeat it.)


-Mark

<contrition><mild>

My apologies since the tone of my previous reply set the tone for yours.
The getFullYear function works as I would expect it to and I'll make use
of it henceforth.

Frankly though since I refactor my entire site every 18-24 months, I'm
less than concerned about the code failing in 95 years. And I assure
you that MS will make sure the code doesn't work as it does now long
before then.

Thank you for the correction. In this case I could have posted the
problem to a scripting group and probably would have been pointed to the
getFullYear function, but under the crunch to get it working I chose the
expedient hack. And now I've been informed, which is why I read through
these posts.
</mild></contrition>

My spell checker just tried to changed getFullYear to fretfully.

 

[Jon]

Such a simple solution p but possibly the better one to try first! Also
you didn't get into a flame match by suggestion ;o) lol

WELL DONE!