ASP cokies problem under i.e.

Discussion in 'ASP General' started by patbaudy, May 28, 2005.

  1. patbaudy

    patbaudy Guest

    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.
     
    patbaudy, May 28, 2005
    #1
    1. Advertising

  2. On Sat, 28 May 2005 16:58:04 GMT, patbaudy <> wrote:
    in <Xns966483ECFD3C5patbaudyhotmailcom@205.237.233.52>

    >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);


    ---
    Stefan Berglund
     
    Stefan Berglund, May 28, 2005
    #2
    1. Advertising

  3. "Stefan Berglund" <> wrote in message
    news:...
    > On Sat, 28 May 2005 16:58:04 GMT, patbaudy <> wrote:
    > in <Xns966483ECFD3C5patbaudyhotmailcom@205.237.233.52>
    >
    >>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.


    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
     
    Mark J. McGinty, May 28, 2005
    #3
  4. On Sat, 28 May 2005 12:09:07 -0700, "Mark J. McGinty"
    <> wrote:
    in <#>

    >
    >"Stefan Berglund" <> wrote in message
    >news:...
    >> On Sat, 28 May 2005 16:58:04 GMT, patbaudy <> wrote:
    >> in <Xns966483ECFD3C5patbaudyhotmailcom@205.237.233.52>
    >>
    >>>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.

    >
    >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


    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);


    ---
    Stefan Berglund
     
    Stefan Berglund, May 29, 2005
    #4
  5. "Stefan Berglund" <> wrote in message
    news:...
    > On Sat, 28 May 2005 12:09:07 -0700, "Mark J. McGinty"
    > <> wrote:
    > in <#>
    >
    >>
    >>"Stefan Berglund" <> wrote in message
    >>news:...
    >>> On Sat, 28 May 2005 16:58:04 GMT, patbaudy <> wrote:
    >>> in <Xns966483ECFD3C5patbaudyhotmailcom@205.237.233.52>
    >>>

    [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


    > 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);
    >
    >
    > ---
    > Stefan Berglund
     
    Mark J. McGinty, May 29, 2005
    #5
  6. On Sun, 29 May 2005 12:35:53 -0700, "Mark J. McGinty"
    <> wrote:
    in <jPome.1210$4p.1148@fed1read03>

    >
    >"Stefan Berglund" <> wrote in message
    >news:...
    >> On Sat, 28 May 2005 12:09:07 -0700, "Mark J. McGinty"
    >> <> wrote:
    >> in <#>
    >>
    >>>
    >>>"Stefan Berglund" <> wrote in message
    >>>news:...
    >>>> On Sat, 28 May 2005 16:58:04 GMT, patbaudy <> wrote:
    >>>> in <Xns966483ECFD3C5patbaudyhotmailcom@205.237.233.52>
    >>>>

    >[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.


    ---
    Stefan Berglund
     
    Stefan Berglund, May 29, 2005
    #6
  7. patbaudy

    Jon Guest

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

    WELL DONE!

    --
    Jon

    Look at that dead pixel on your screen! *SLAP* Gotcha!
    "John Blessing" <jb@**REMOVE**THIS**Lbesoftware.com> wrote in message
    news:8lmme.836$...
    > "patbaudy" <> wrote in message
    > news:Xns966483ECFD3C5patbaudyhotmailcom@205.237.233.52...
    >> 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

    >
    >
    > Make sure cookies are enabled in your browser - Tools, Internet Options,
    > Privacy, Advanced, check the box "Always allow session cookies"
    >
    >
    > --
    > John Blessing
    >
    > http://www.LbeHelpdesk.com - Help Desk software priced to suit all
    > businesses
    > http://www.room-booking-software.com - Schedule rooms & equipment bookings
    > for your meeting/class over the web.
    > http://www.lbetoolbox.com - Remove Duplicates from MS Outlook
    >
     
    Jon, May 30, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. oreng
    Replies:
    1
    Views:
    6,716
    Tamir Khason
    Jul 7, 2004
  2. hshdude
    Replies:
    12
    Views:
    1,108
    Dimitri Maziuk
    Nov 4, 2004
  3. bronby
    Replies:
    1
    Views:
    667
    Andrew Thompson
    Jul 15, 2005
  4. Edward V. Berard
    Replies:
    4
    Views:
    940
    John B. Matthews
    Apr 4, 2006
  5. Richard
    Replies:
    4
    Views:
    182
    Richard
    Jan 25, 2007
Loading...

Share This Page