Response.Cookies bug

Discussion in 'ASP General' started by Mark, Feb 28, 2005.

  1. Mark

    Mark Guest

    Hi...

    I've come across some weird bug with Response.Cookies. Or maybe it will be
    called "by design" but for the life of me I can't figure out what purpose it
    would serve. If you're setting a cookie (say Response.Cookies ("TEST")) and
    you have a query string variable &test=x or &Test=x and you get
    Request.QueryString to parse the query string, the cookie that gets dropped
    matches the case of the query string, not what your code says. In other
    words even though the code says Response.Cookies ("TEST"), it drops
    Response.Cookies ("test") instead.

    Anyone have any idea what's going on here? There's an example below. Try
    it with http://127.0.0.1/cookieTest.asp?test=x and without the query string
    variable.

    <%@Language=Jscript Enablesessionstate=false%>
    <% var exp = new Date();
    exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    exp.getUTCFullYear()

    var x = Request.QueryString ("dummy");
    Response.Cookies("TEST") = "This is a test";
    Response.Cookies("TEST").Expires = expDate;
    %>

    Thanks
    _mark
    Mark, Feb 28, 2005
    #1
    1. Advertising

  2. Mark

    Mark Schupp Guest

    2 problems.

    Your question does not make any sense to me.
    Your example page does not display anything.

    Please restate the problem as clearly as possible with examples of the what
    you expect to see that you are not seeing happen.

    If possible, provide a sample page that displays the difference.

    --
    Mark Schupp
    Head of Development
    Integrity eLearning
    www.ielearning.com


    "Mark" <> wrote in message
    news:...
    > Hi...
    >
    > I've come across some weird bug with Response.Cookies. Or maybe it will

    be
    > called "by design" but for the life of me I can't figure out what purpose

    it
    > would serve. If you're setting a cookie (say Response.Cookies ("TEST"))

    and
    > you have a query string variable &test=x or &Test=x and you get
    > Request.QueryString to parse the query string, the cookie that gets

    dropped
    > matches the case of the query string, not what your code says. In other
    > words even though the code says Response.Cookies ("TEST"), it drops
    > Response.Cookies ("test") instead.
    >
    > Anyone have any idea what's going on here? There's an example below. Try
    > it with http://127.0.0.1/cookieTest.asp?test=x and without the query

    string
    > variable.
    >
    > <%@Language=Jscript Enablesessionstate=false%>
    > <% var exp = new Date();
    > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    > exp.getUTCFullYear()
    >
    > var x = Request.QueryString ("dummy");
    > Response.Cookies("TEST") = "This is a test";
    > Response.Cookies("TEST").Expires = expDate;
    > %>
    >
    > Thanks
    > _mark
    Mark Schupp, Feb 28, 2005
    #2
    1. Advertising

  3. Mark

    Mark Guest

    Sorry... The point is to look at the cookie-setting that is done in the
    response. Adding a lot of code to dump out the current cookie state I
    thought would gum up the example.

    The main point is that given the code below, one would expect *always* to see

    Set-Cookie: TEST=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00 GMT; path=/

    as a header response for this page, since the name and case of the cookie is
    a hard-coded literal value in the code. The bug in IIS is that if you have,
    say, &test=x on your query string, IIS returns

    Set-Cookie: test=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00 GMT; path=/

    as the cookie setting (notice the case difference).

    This is a problem because when you look for Request.Cookies on subsequent
    page views, those *are* case sensative, so the fact that you're not setting
    the cookie you think you are can cause a lot of problems.

    The response header case-insensativity problem only seems to occur
    a) when there a querystring variable exists with some other representation
    of the name and
    b) when the code uses Request.QueryString ("var") to get the Request object
    to parse the query string. Note that you don't even have to be looking for
    the variable (sort of) sharing the cookie name; anything to get Request to
    parse the query string into a collection.

    If you leave &test=x off of the url or if you take out the
    var x = Request.QueryString ("dummy");
    line, you get the first, correct cookie header as a response.

    Thanks
    _mark


    "Mark Schupp" wrote:

    > 2 problems.
    >
    > Your question does not make any sense to me.
    > Your example page does not display anything.
    >
    > Please restate the problem as clearly as possible with examples of the what
    > you expect to see that you are not seeing happen.
    >
    > If possible, provide a sample page that displays the difference.
    >
    > --
    > Mark Schupp
    > Head of Development
    > Integrity eLearning
    > www.ielearning.com
    >
    >
    > "Mark" <> wrote in message
    > news:...
    > > Hi...
    > >
    > > I've come across some weird bug with Response.Cookies. Or maybe it will

    > be
    > > called "by design" but for the life of me I can't figure out what purpose

    > it
    > > would serve. If you're setting a cookie (say Response.Cookies ("TEST"))

    > and
    > > you have a query string variable &test=x or &Test=x and you get
    > > Request.QueryString to parse the query string, the cookie that gets

    > dropped
    > > matches the case of the query string, not what your code says. In other
    > > words even though the code says Response.Cookies ("TEST"), it drops
    > > Response.Cookies ("test") instead.
    > >
    > > Anyone have any idea what's going on here? There's an example below. Try
    > > it with http://127.0.0.1/cookieTest.asp?test=x and without the query

    > string
    > > variable.
    > >
    > > <%@Language=Jscript Enablesessionstate=false%>
    > > <% var exp = new Date();
    > > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    > > exp.getUTCFullYear()
    > >
    > > var x = Request.QueryString ("dummy");
    > > Response.Cookies("TEST") = "This is a test";
    > > Response.Cookies("TEST").Expires = expDate;
    > > %>
    > >
    > > Thanks
    > > _mark

    >
    >
    >
    Mark, Feb 28, 2005
    #3
  4. Mark

    Mark Schupp Guest

    possibly I am missing something (I'm not all that knowledgable about
    cookies) but the cookie collection does not appear to be case-sensitive.

    Running the below code gives the same value for "TEST" as for "test" on the
    second request (all cookies were deleted first).

    %@Language=Jscript Enablesessionstate=false%>
    <% var exp = new Date();
    exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    exp.getUTCFullYear()

    Response.Write( "TEST cookie:" + Request.Cookies("TEST") + "<br>" );
    Response.Write( "test cookie:" + Request.Cookies("test") + "<br>" );

    var x = Request.QueryString ("dummy");
    Response.Cookies("TEST") = "This is a test";
    Response.Cookies("TEST").Expires = expDate;
    %>


    --
    Mark Schupp
    Head of Development
    Integrity eLearning
    www.ielearning.com


    "Mark" <> wrote in message
    news:...
    > Sorry... The point is to look at the cookie-setting that is done in the
    > response. Adding a lot of code to dump out the current cookie state I
    > thought would gum up the example.
    >
    > The main point is that given the code below, one would expect *always* to

    see
    >
    > Set-Cookie: TEST=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00 GMT;

    path=/
    >
    > as a header response for this page, since the name and case of the cookie

    is
    > a hard-coded literal value in the code. The bug in IIS is that if you

    have,
    > say, &test=x on your query string, IIS returns
    >
    > Set-Cookie: test=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00 GMT;

    path=/
    >
    > as the cookie setting (notice the case difference).
    >
    > This is a problem because when you look for Request.Cookies on subsequent
    > page views, those *are* case sensative, so the fact that you're not

    setting
    > the cookie you think you are can cause a lot of problems.
    >
    > The response header case-insensativity problem only seems to occur
    > a) when there a querystring variable exists with some other representation
    > of the name and
    > b) when the code uses Request.QueryString ("var") to get the Request

    object
    > to parse the query string. Note that you don't even have to be looking

    for
    > the variable (sort of) sharing the cookie name; anything to get Request to
    > parse the query string into a collection.
    >
    > If you leave &test=x off of the url or if you take out the
    > var x = Request.QueryString ("dummy");
    > line, you get the first, correct cookie header as a response.
    >
    > Thanks
    > _mark
    >
    >
    > "Mark Schupp" wrote:
    >
    > > 2 problems.
    > >
    > > Your question does not make any sense to me.
    > > Your example page does not display anything.
    > >
    > > Please restate the problem as clearly as possible with examples of the

    what
    > > you expect to see that you are not seeing happen.
    > >
    > > If possible, provide a sample page that displays the difference.
    > >
    > > --
    > > Mark Schupp
    > > Head of Development
    > > Integrity eLearning
    > > www.ielearning.com
    > >
    > >
    > > "Mark" <> wrote in message
    > > news:...
    > > > Hi...
    > > >
    > > > I've come across some weird bug with Response.Cookies. Or maybe it

    will
    > > be
    > > > called "by design" but for the life of me I can't figure out what

    purpose
    > > it
    > > > would serve. If you're setting a cookie (say Response.Cookies

    ("TEST"))
    > > and
    > > > you have a query string variable &test=x or &Test=x and you get
    > > > Request.QueryString to parse the query string, the cookie that gets

    > > dropped
    > > > matches the case of the query string, not what your code says. In

    other
    > > > words even though the code says Response.Cookies ("TEST"), it drops
    > > > Response.Cookies ("test") instead.
    > > >
    > > > Anyone have any idea what's going on here? There's an example below.

    Try
    > > > it with http://127.0.0.1/cookieTest.asp?test=x and without the query

    > > string
    > > > variable.
    > > >
    > > > <%@Language=Jscript Enablesessionstate=false%>
    > > > <% var exp = new Date();
    > > > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > > > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    > > > exp.getUTCFullYear()
    > > >
    > > > var x = Request.QueryString ("dummy");
    > > > Response.Cookies("TEST") = "This is a test";
    > > > Response.Cookies("TEST").Expires = expDate;
    > > > %>
    > > >
    > > > Thanks
    > > > _mark

    > >
    > >
    > >
    Mark Schupp, Feb 28, 2005
    #4
  5. Mark

    Mark Guest

    Hi Mark...

    Okay, now this is getting a little weird. After seeing your post, I went to
    www.w3c.org and read sections of rfc2965 about cookies, and it does say in
    there that the names of the cookies are case-insensitive, so the fact that
    IIS behaves inconsistently could be argued as not a bug, but then the bug
    just moves to IE, which is treating the cookie names as case-*sensitive*.

    I.e. If I get the first reported problem to happen (the name of the cookie
    switches case), from then on, IE will pass up *both* versions of the cookie
    and the upper case one seems to trump the lower case one when you go to look
    for it. In other words, you can never find that lower case cookie in ASP
    even though IE is sending both back up.

    Further muddying the waters is that your modification (referencing
    Request.Cookies("TEST")) seems to undo whatever state in IIS gets the state
    mixed up in the first place. If you're watching the headers returned from
    the page with your modifications, the cookies in question *don't* switch case
    on their names anymore. If you comment out those lines and just watch the
    headers, IIS is messing with the case.

    I made another small mod on your mod so that now it will set the cookie with
    the querystring value, if any. Otherwise it sets it with the time of day.
    Adding this on below. So in summary, it seems like IIS has a small bug that
    MS might try to explain away as "acceptible inconsistency" and IE has a bug
    in that it doesn't manage cookies of similar names properly.

    <%@Language=Jscript Enablesessionstate=false%>
    <% var exp = new Date();
    exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    exp.getUTCFullYear()

    //Response.Write( "TEST cookie:" + Request.Cookies("TEST") + "<br>" );
    //Response.Write( "test cookie:" + Request.Cookies("test") + "<br>" );

    var x = Request.QueryString ("test");
    if (String (x) == "undefined") x = (new Date()).toString();
    Response.Cookies("TEST") = x;
    Response.Cookies("TEST").Expires = expDate;
    %>


    Thanks
    -mark


    "Mark Schupp" wrote:

    > possibly I am missing something (I'm not all that knowledgable about
    > cookies) but the cookie collection does not appear to be case-sensitive.
    >
    > Running the below code gives the same value for "TEST" as for "test" on the
    > second request (all cookies were deleted first).
    >
    > %@Language=Jscript Enablesessionstate=false%>
    > <% var exp = new Date();
    > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    > exp.getUTCFullYear()
    >
    > Response.Write( "TEST cookie:" + Request.Cookies("TEST") + "<br>" );
    > Response.Write( "test cookie:" + Request.Cookies("test") + "<br>" );
    >
    > var x = Request.QueryString ("dummy");
    > Response.Cookies("TEST") = "This is a test";
    > Response.Cookies("TEST").Expires = expDate;
    > %>
    >
    >
    > --
    > Mark Schupp
    > Head of Development
    > Integrity eLearning
    > www.ielearning.com
    >
    >
    > "Mark" <> wrote in message
    > news:...
    > > Sorry... The point is to look at the cookie-setting that is done in the
    > > response. Adding a lot of code to dump out the current cookie state I
    > > thought would gum up the example.
    > >
    > > The main point is that given the code below, one would expect *always* to

    > see
    > >
    > > Set-Cookie: TEST=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00 GMT;

    > path=/
    > >
    > > as a header response for this page, since the name and case of the cookie

    > is
    > > a hard-coded literal value in the code. The bug in IIS is that if you

    > have,
    > > say, &test=x on your query string, IIS returns
    > >
    > > Set-Cookie: test=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00 GMT;

    > path=/
    > >
    > > as the cookie setting (notice the case difference).
    > >
    > > This is a problem because when you look for Request.Cookies on subsequent
    > > page views, those *are* case sensative, so the fact that you're not

    > setting
    > > the cookie you think you are can cause a lot of problems.
    > >
    > > The response header case-insensativity problem only seems to occur
    > > a) when there a querystring variable exists with some other representation
    > > of the name and
    > > b) when the code uses Request.QueryString ("var") to get the Request

    > object
    > > to parse the query string. Note that you don't even have to be looking

    > for
    > > the variable (sort of) sharing the cookie name; anything to get Request to
    > > parse the query string into a collection.
    > >
    > > If you leave &test=x off of the url or if you take out the
    > > var x = Request.QueryString ("dummy");
    > > line, you get the first, correct cookie header as a response.
    > >
    > > Thanks
    > > _mark
    > >
    > >
    > > "Mark Schupp" wrote:
    > >
    > > > 2 problems.
    > > >
    > > > Your question does not make any sense to me.
    > > > Your example page does not display anything.
    > > >
    > > > Please restate the problem as clearly as possible with examples of the

    > what
    > > > you expect to see that you are not seeing happen.
    > > >
    > > > If possible, provide a sample page that displays the difference.
    > > >
    > > > --
    > > > Mark Schupp
    > > > Head of Development
    > > > Integrity eLearning
    > > > www.ielearning.com
    > > >
    > > >
    > > > "Mark" <> wrote in message
    > > > news:...
    > > > > Hi...
    > > > >
    > > > > I've come across some weird bug with Response.Cookies. Or maybe it

    > will
    > > > be
    > > > > called "by design" but for the life of me I can't figure out what

    > purpose
    > > > it
    > > > > would serve. If you're setting a cookie (say Response.Cookies

    > ("TEST"))
    > > > and
    > > > > you have a query string variable &test=x or &Test=x and you get
    > > > > Request.QueryString to parse the query string, the cookie that gets
    > > > dropped
    > > > > matches the case of the query string, not what your code says. In

    > other
    > > > > words even though the code says Response.Cookies ("TEST"), it drops
    > > > > Response.Cookies ("test") instead.
    > > > >
    > > > > Anyone have any idea what's going on here? There's an example below.

    > Try
    > > > > it with http://127.0.0.1/cookieTest.asp?test=x and without the query
    > > > string
    > > > > variable.
    > > > >
    > > > > <%@Language=Jscript Enablesessionstate=false%>
    > > > > <% var exp = new Date();
    > > > > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > > > > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    > > > > exp.getUTCFullYear()
    > > > >
    > > > > var x = Request.QueryString ("dummy");
    > > > > Response.Cookies("TEST") = "This is a test";
    > > > > Response.Cookies("TEST").Expires = expDate;
    > > > > %>
    > > > >
    > > > > Thanks
    > > > > _mark
    > > >
    > > >
    > > >

    >
    >
    >
    Mark, Feb 28, 2005
    #5
  6. Mark

    Mark Schupp Guest

    Can you post a simple page that demonstrates the problem on the IE side?

    --
    Mark Schupp
    Head of Development
    Integrity eLearning
    www.ielearning.com


    "Mark" <> wrote in message
    news:...
    > Hi Mark...
    >
    > Okay, now this is getting a little weird. After seeing your post, I went

    to
    > www.w3c.org and read sections of rfc2965 about cookies, and it does say in
    > there that the names of the cookies are case-insensitive, so the fact that
    > IIS behaves inconsistently could be argued as not a bug, but then the bug
    > just moves to IE, which is treating the cookie names as case-*sensitive*.
    >
    > I.e. If I get the first reported problem to happen (the name of the cookie
    > switches case), from then on, IE will pass up *both* versions of the

    cookie
    > and the upper case one seems to trump the lower case one when you go to

    look
    > for it. In other words, you can never find that lower case cookie in ASP
    > even though IE is sending both back up.
    >
    > Further muddying the waters is that your modification (referencing
    > Request.Cookies("TEST")) seems to undo whatever state in IIS gets the

    state
    > mixed up in the first place. If you're watching the headers returned from
    > the page with your modifications, the cookies in question *don't* switch

    case
    > on their names anymore. If you comment out those lines and just watch the
    > headers, IIS is messing with the case.
    >
    > I made another small mod on your mod so that now it will set the cookie

    with
    > the querystring value, if any. Otherwise it sets it with the time of day.
    > Adding this on below. So in summary, it seems like IIS has a small bug

    that
    > MS might try to explain away as "acceptible inconsistency" and IE has a

    bug
    > in that it doesn't manage cookies of similar names properly.
    >
    > <%@Language=Jscript Enablesessionstate=false%>
    > <% var exp = new Date();
    > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    > exp.getUTCFullYear()
    >
    > //Response.Write( "TEST cookie:" + Request.Cookies("TEST") + "<br>" );
    > //Response.Write( "test cookie:" + Request.Cookies("test") + "<br>" );
    >
    > var x = Request.QueryString ("test");
    > if (String (x) == "undefined") x = (new Date()).toString();
    > Response.Cookies("TEST") = x;
    > Response.Cookies("TEST").Expires = expDate;
    > %>
    >
    >
    > Thanks
    > -mark
    >
    >
    > "Mark Schupp" wrote:
    >
    > > possibly I am missing something (I'm not all that knowledgable about
    > > cookies) but the cookie collection does not appear to be case-sensitive.
    > >
    > > Running the below code gives the same value for "TEST" as for "test" on

    the
    > > second request (all cookies were deleted first).
    > >
    > > %@Language=Jscript Enablesessionstate=false%>
    > > <% var exp = new Date();
    > > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    > > exp.getUTCFullYear()
    > >
    > > Response.Write( "TEST cookie:" + Request.Cookies("TEST") + "<br>" );
    > > Response.Write( "test cookie:" + Request.Cookies("test") + "<br>" );
    > >
    > > var x = Request.QueryString ("dummy");
    > > Response.Cookies("TEST") = "This is a test";
    > > Response.Cookies("TEST").Expires = expDate;
    > > %>
    > >
    > >
    > > --
    > > Mark Schupp
    > > Head of Development
    > > Integrity eLearning
    > > www.ielearning.com
    > >
    > >
    > > "Mark" <> wrote in message
    > > news:...
    > > > Sorry... The point is to look at the cookie-setting that is done in

    the
    > > > response. Adding a lot of code to dump out the current cookie state I
    > > > thought would gum up the example.
    > > >
    > > > The main point is that given the code below, one would expect *always*

    to
    > > see
    > > >
    > > > Set-Cookie: TEST=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00

    GMT;
    > > path=/
    > > >
    > > > as a header response for this page, since the name and case of the

    cookie
    > > is
    > > > a hard-coded literal value in the code. The bug in IIS is that if you

    > > have,
    > > > say, &test=x on your query string, IIS returns
    > > >
    > > > Set-Cookie: test=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00

    GMT;
    > > path=/
    > > >
    > > > as the cookie setting (notice the case difference).
    > > >
    > > > This is a problem because when you look for Request.Cookies on

    subsequent
    > > > page views, those *are* case sensative, so the fact that you're not

    > > setting
    > > > the cookie you think you are can cause a lot of problems.
    > > >
    > > > The response header case-insensativity problem only seems to occur
    > > > a) when there a querystring variable exists with some other

    representation
    > > > of the name and
    > > > b) when the code uses Request.QueryString ("var") to get the Request

    > > object
    > > > to parse the query string. Note that you don't even have to be

    looking
    > > for
    > > > the variable (sort of) sharing the cookie name; anything to get

    Request to
    > > > parse the query string into a collection.
    > > >
    > > > If you leave &test=x off of the url or if you take out the
    > > > var x = Request.QueryString ("dummy");
    > > > line, you get the first, correct cookie header as a response.
    > > >
    > > > Thanks
    > > > _mark
    > > >
    > > >
    > > > "Mark Schupp" wrote:
    > > >
    > > > > 2 problems.
    > > > >
    > > > > Your question does not make any sense to me.
    > > > > Your example page does not display anything.
    > > > >
    > > > > Please restate the problem as clearly as possible with examples of

    the
    > > what
    > > > > you expect to see that you are not seeing happen.
    > > > >
    > > > > If possible, provide a sample page that displays the difference.
    > > > >
    > > > > --
    > > > > Mark Schupp
    > > > > Head of Development
    > > > > Integrity eLearning
    > > > > www.ielearning.com
    > > > >
    > > > >
    > > > > "Mark" <> wrote in message
    > > > > news:...
    > > > > > Hi...
    > > > > >
    > > > > > I've come across some weird bug with Response.Cookies. Or maybe

    it
    > > will
    > > > > be
    > > > > > called "by design" but for the life of me I can't figure out what

    > > purpose
    > > > > it
    > > > > > would serve. If you're setting a cookie (say Response.Cookies

    > > ("TEST"))
    > > > > and
    > > > > > you have a query string variable &test=x or &Test=x and you get
    > > > > > Request.QueryString to parse the query string, the cookie that

    gets
    > > > > dropped
    > > > > > matches the case of the query string, not what your code says. In

    > > other
    > > > > > words even though the code says Response.Cookies ("TEST"), it

    drops
    > > > > > Response.Cookies ("test") instead.
    > > > > >
    > > > > > Anyone have any idea what's going on here? There's an example

    below.
    > > Try
    > > > > > it with http://127.0.0.1/cookieTest.asp?test=x and without the

    query
    > > > > string
    > > > > > variable.
    > > > > >
    > > > > > <%@Language=Jscript Enablesessionstate=false%>
    > > > > > <% var exp = new Date();
    > > > > > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > > > > > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/"

    +
    > > > > > exp.getUTCFullYear()
    > > > > >
    > > > > > var x = Request.QueryString ("dummy");
    > > > > > Response.Cookies("TEST") = "This is a test";
    > > > > > Response.Cookies("TEST").Expires = expDate;
    > > > > > %>
    > > > > >
    > > > > > Thanks
    > > > > > _mark
    > > > >
    > > > >
    > > > >

    > >
    > >
    > >
    Mark Schupp, Feb 28, 2005
    #6
  7. Mark

    Mark Guest

    Hi Mark...

    Generally, I've been using proxytrace to watch the headers going back and
    forth, demonstrating the problem. Otherwise, you could look at the cookies
    files on your IE side to see it.

    If you set a cookie "TEST" and a cookie "test" for the same host/ie instance
    pair, you'll see that on the IE side, it's treating them case-sensitively -
    i.e. you get two different cookies with two different values. If you go back
    to that host, IE will present both cookies to IIS. As your example
    demonstrated, IIS is treating the names case-insensitively (upper trumps
    lower).

    The nub is that either cookie names are supposed to be case-insensitive or
    they're not. IIS is being pretty loose about case-sensitivity but it could
    be argued the standard lets them be. IE is being strictly case sensitive in
    the management of the cookies, which interacts with IIS in strange ways.

    I'm writing it up and submitting it to the MS bug-report line now
    (unfortunately our msdn subscription is in the process of being renewed, or I
    just would have called them up).

    Thanks
    -mark


    "Mark Schupp" wrote:

    > Can you post a simple page that demonstrates the problem on the IE side?
    >
    > --
    > Mark Schupp
    > Head of Development
    > Integrity eLearning
    > www.ielearning.com
    >
    >
    > "Mark" <> wrote in message
    > news:...
    > > Hi Mark...
    > >
    > > Okay, now this is getting a little weird. After seeing your post, I went

    > to
    > > www.w3c.org and read sections of rfc2965 about cookies, and it does say in
    > > there that the names of the cookies are case-insensitive, so the fact that
    > > IIS behaves inconsistently could be argued as not a bug, but then the bug
    > > just moves to IE, which is treating the cookie names as case-*sensitive*.
    > >
    > > I.e. If I get the first reported problem to happen (the name of the cookie
    > > switches case), from then on, IE will pass up *both* versions of the

    > cookie
    > > and the upper case one seems to trump the lower case one when you go to

    > look
    > > for it. In other words, you can never find that lower case cookie in ASP
    > > even though IE is sending both back up.
    > >
    > > Further muddying the waters is that your modification (referencing
    > > Request.Cookies("TEST")) seems to undo whatever state in IIS gets the

    > state
    > > mixed up in the first place. If you're watching the headers returned from
    > > the page with your modifications, the cookies in question *don't* switch

    > case
    > > on their names anymore. If you comment out those lines and just watch the
    > > headers, IIS is messing with the case.
    > >
    > > I made another small mod on your mod so that now it will set the cookie

    > with
    > > the querystring value, if any. Otherwise it sets it with the time of day.
    > > Adding this on below. So in summary, it seems like IIS has a small bug

    > that
    > > MS might try to explain away as "acceptible inconsistency" and IE has a

    > bug
    > > in that it doesn't manage cookies of similar names properly.
    > >
    > > <%@Language=Jscript Enablesessionstate=false%>
    > > <% var exp = new Date();
    > > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    > > exp.getUTCFullYear()
    > >
    > > //Response.Write( "TEST cookie:" + Request.Cookies("TEST") + "<br>" );
    > > //Response.Write( "test cookie:" + Request.Cookies("test") + "<br>" );
    > >
    > > var x = Request.QueryString ("test");
    > > if (String (x) == "undefined") x = (new Date()).toString();
    > > Response.Cookies("TEST") = x;
    > > Response.Cookies("TEST").Expires = expDate;
    > > %>
    > >
    > >
    > > Thanks
    > > -mark
    > >
    > >
    > > "Mark Schupp" wrote:
    > >
    > > > possibly I am missing something (I'm not all that knowledgable about
    > > > cookies) but the cookie collection does not appear to be case-sensitive.
    > > >
    > > > Running the below code gives the same value for "TEST" as for "test" on

    > the
    > > > second request (all cookies were deleted first).
    > > >
    > > > %@Language=Jscript Enablesessionstate=false%>
    > > > <% var exp = new Date();
    > > > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > > > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/" +
    > > > exp.getUTCFullYear()
    > > >
    > > > Response.Write( "TEST cookie:" + Request.Cookies("TEST") + "<br>" );
    > > > Response.Write( "test cookie:" + Request.Cookies("test") + "<br>" );
    > > >
    > > > var x = Request.QueryString ("dummy");
    > > > Response.Cookies("TEST") = "This is a test";
    > > > Response.Cookies("TEST").Expires = expDate;
    > > > %>
    > > >
    > > >
    > > > --
    > > > Mark Schupp
    > > > Head of Development
    > > > Integrity eLearning
    > > > www.ielearning.com
    > > >
    > > >
    > > > "Mark" <> wrote in message
    > > > news:...
    > > > > Sorry... The point is to look at the cookie-setting that is done in

    > the
    > > > > response. Adding a lot of code to dump out the current cookie state I
    > > > > thought would gum up the example.
    > > > >
    > > > > The main point is that given the code below, one would expect *always*

    > to
    > > > see
    > > > >
    > > > > Set-Cookie: TEST=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00

    > GMT;
    > > > path=/
    > > > >
    > > > > as a header response for this page, since the name and case of the

    > cookie
    > > > is
    > > > > a hard-coded literal value in the code. The bug in IIS is that if you
    > > > have,
    > > > > say, &test=x on your query string, IIS returns
    > > > >
    > > > > Set-Cookie: test=This+is+a+test; expires=Wed, 28-Feb-2007 05:00:00

    > GMT;
    > > > path=/
    > > > >
    > > > > as the cookie setting (notice the case difference).
    > > > >
    > > > > This is a problem because when you look for Request.Cookies on

    > subsequent
    > > > > page views, those *are* case sensative, so the fact that you're not
    > > > setting
    > > > > the cookie you think you are can cause a lot of problems.
    > > > >
    > > > > The response header case-insensativity problem only seems to occur
    > > > > a) when there a querystring variable exists with some other

    > representation
    > > > > of the name and
    > > > > b) when the code uses Request.QueryString ("var") to get the Request
    > > > object
    > > > > to parse the query string. Note that you don't even have to be

    > looking
    > > > for
    > > > > the variable (sort of) sharing the cookie name; anything to get

    > Request to
    > > > > parse the query string into a collection.
    > > > >
    > > > > If you leave &test=x off of the url or if you take out the
    > > > > var x = Request.QueryString ("dummy");
    > > > > line, you get the first, correct cookie header as a response.
    > > > >
    > > > > Thanks
    > > > > _mark
    > > > >
    > > > >
    > > > > "Mark Schupp" wrote:
    > > > >
    > > > > > 2 problems.
    > > > > >
    > > > > > Your question does not make any sense to me.
    > > > > > Your example page does not display anything.
    > > > > >
    > > > > > Please restate the problem as clearly as possible with examples of

    > the
    > > > what
    > > > > > you expect to see that you are not seeing happen.
    > > > > >
    > > > > > If possible, provide a sample page that displays the difference.
    > > > > >
    > > > > > --
    > > > > > Mark Schupp
    > > > > > Head of Development
    > > > > > Integrity eLearning
    > > > > > www.ielearning.com
    > > > > >
    > > > > >
    > > > > > "Mark" <> wrote in message
    > > > > > news:...
    > > > > > > Hi...
    > > > > > >
    > > > > > > I've come across some weird bug with Response.Cookies. Or maybe

    > it
    > > > will
    > > > > > be
    > > > > > > called "by design" but for the life of me I can't figure out what
    > > > purpose
    > > > > > it
    > > > > > > would serve. If you're setting a cookie (say Response.Cookies
    > > > ("TEST"))
    > > > > > and
    > > > > > > you have a query string variable &test=x or &Test=x and you get
    > > > > > > Request.QueryString to parse the query string, the cookie that

    > gets
    > > > > > dropped
    > > > > > > matches the case of the query string, not what your code says. In
    > > > other
    > > > > > > words even though the code says Response.Cookies ("TEST"), it

    > drops
    > > > > > > Response.Cookies ("test") instead.
    > > > > > >
    > > > > > > Anyone have any idea what's going on here? There's an example

    > below.
    > > > Try
    > > > > > > it with http://127.0.0.1/cookieTest.asp?test=x and without the

    > query
    > > > > > string
    > > > > > > variable.
    > > > > > >
    > > > > > > <%@Language=Jscript Enablesessionstate=false%>
    > > > > > > <% var exp = new Date();
    > > > > > > exp.setTime(exp.getTime() + (2 * 365 * 24 * 60 * 60 * 1000))
    > > > > > > var expDate = (exp.getUTCMonth()+1) + "/" + exp.getUTCDate() + "/"

    > +
    > > > > > > exp.getUTCFullYear()
    > > > > > >
    > > > > > > var x = Request.QueryString ("dummy");
    > > > > > > Response.Cookies("TEST") = "This is a test";
    > > > > > > Response.Cookies("TEST").Expires = expDate;
    > > > > > > %>
    > > > > > >
    > > > > > > Thanks
    > > > > > > _mark
    > > > > >
    > > > > >
    > > > > >
    > > >
    > > >
    > > >

    >
    >
    >
    Mark, Feb 28, 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. Alex Nitulescu

    Response.Cookies vs Request.Cookies

    Alex Nitulescu, Feb 3, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    8,452
    Hans Kesting
    Feb 3, 2005
  2. Andy Fish
    Replies:
    3
    Views:
    6,502
    Fredrik Lindner
    Nov 6, 2003
  3. user
    Replies:
    3
    Views:
    647
    =?ISO-8859-1?Q?G=F6ran_Andersson?=
    Mar 31, 2007
  4. _Who
    Replies:
    7
    Views:
    2,630
  5. Cal Who

    Response.cookies vs Request.cookies

    Cal Who, Dec 5, 2009, in forum: ASP .Net
    Replies:
    7
    Views:
    1,480
    Gregory A. Beamer
    Dec 10, 2009
Loading...

Share This Page