Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Response.Cookies bug

6 views
Skip to first unread message

Mark

unread,
Feb 28, 2005, 11:09:02 AM2/28/05
to
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

unread,
Feb 28, 2005, 12:13:28 PM2/28/05
to
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" <mmod...@nospam.nospam> wrote in message
news:196C89FB-6744-4717...@microsoft.com...

Mark

unread,
Feb 28, 2005, 12:59:05 PM2/28/05
to
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

unread,
Feb 28, 2005, 2:05:33 PM2/28/05
to
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" <mmod...@nospam.nospam> wrote in message

news:C1EA1F3F-FB10-4D54...@microsoft.com...

Mark

unread,
Feb 28, 2005, 3:19:03 PM2/28/05
to
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

unread,
Feb 28, 2005, 3:27:19 PM2/28/05
to
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" <mmod...@nospam.nospam> wrote in message

news:E0A5E529-72E2-4244...@microsoft.com...

Mark

unread,
Feb 28, 2005, 3:59:02 PM2/28/05
to
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).

0 new messages