sending http requests without cookies

[yawnmoth]

Say I wrote an ajax script to send out HTTP requests via ajax. Any
cookies that I have associated with that site will be sent along with
this HTTP request. Is there a way to prevent this from happening? I
tried the following to no avail:

http.setRequestHeader('Cookie','');

 

[VK]

Say I wrote an ajax script to send out HTTP requests via ajax. Any
cookies that I have associated with that site will be sent along with
this HTTP request. Is there a way to prevent this from happening? I
tried the following to no avail:

http.setRequestHeader('Cookie','');

var tmp = document.cookie;
document.cookie = '';
sendRequest();
document.cookie = tmp;

( ? )

 

[Thomas 'PointedEars' Lahn]

I don't think so. Why would that be necessary anyway?

This cannot work because the Cookie header value must not be empty.
See RFC2965, 3.3.4.

var tmp = document.cookie;
document.cookie = '';
sendRequest();
document.cookie = tmp;

( ? )

Definitely not. As can be proven easily, assigning the empty string to
document.cookie does not delete all cookies for this resource.

It merely adds a new session cookie with empty name and value for the
current domain and path -- although that particular behavior may be
UA-dependent (I tested with Firefox 1.5.0.1/Linux).

Tests with that UA also indicate that since it is not possible to determine
what the domain and path components were when a cookie was set, it is not
possible to delete it reliably using the value of document.cookies only as
it is not possible to delete a cookie when domain and path component do not
match (implicitly).


PointedEars

 

[VK]

I don't think so. Why would that be necessary anyway?


This cannot work because the Cookie header value must not be empty.
See RFC2965, 3.3.4.


Definitely not. As can be proven easily, assigning the empty string to
document.cookie does not delete all cookies for this resource.

Right. I forgot (it was a while I played with cookies client-side) that
cookie property works like an electric diod: it has different
"resistance" depending on what side of expression it is used.

On the right side it has "zero resistance" so by saying:
var foo = document.cookie;
you are grabbing all cookies with all attributes available for the
given document.

On the left side it has "high resistance" so you can address only one
cookie at time, so by saying:
document.cookie = foo;
document.cookie = bar;
you are not overriding foo by bar, but setting two separate cookies
(foo and bar).

So the proposed algorithm, if it's indeed the only way (I don't know
and actually I hope not) must be adjusted into a much more complicated
way:

1) grab all cookies by
var foo = document.cookie;

2) Parse cookie string "foo", extract each separate cookie and make it
expired (or override it with empty string):
document.cookie = cookie1;
document.cookie = cookie2;
etc.

3) Send request.

4) Restore all cookies back using the same algorithm as on step 2.

For one of these "update every 10ms" ajaxoids this approach is very
questionnable to work. For a single or rare requests it is doable:
again if there is nothing better than that.

 

[Thomas 'PointedEars' Lahn]

yawnmoth wrote:
Say I wrote an ajax script to send out HTTP requests via ajax. Any
cookies that I have associated with that site will be sent along with
this HTTP request. Is there a way to prevent this from happening? [...]
var tmp = document.cookie;
document.cookie = '';
sendRequest();
document.cookie = tmp;

( ? )

Definitely not. As can be proven easily, assigning the empty string to
document.cookie does not delete all cookies for this resource.

[...]
So the proposed algorithm, if it's indeed the only way (I don't know
and actually I hope not) must be adjusted into a much more complicated
way:

1) grab all cookies by
var foo = document.cookie;

2) Parse cookie string "foo", extract each separate cookie and make it
expired (or override it with empty string):
document.cookie = cookie1;
document.cookie = cookie2;
etc.

As I said, step 2 is not possible. Once in a while you should read what
you reply to.


PointedEars

 

[VK]

As I said, step 2 is not possible. Once in a while you should read what
you reply to.

What do you mean "impossible"? How do you think all JavaScript cookie
management systems work?

Read some manual like
<http://www.netspade.com/articles/2005/11/16/javascript-cookies/>

 

[Thomas 'PointedEars' Lahn]

What do you mean "impossible"?

Impossible as in "not possible".

How do you think all JavaScript cookie management systems work?

I do not know. Why do you think that is relevant? The reference
implementation does not support it already.

Read some manual like
<http://www.netspade.com/articles/2005/11/16/javascript-cookies/>

Read the comments for the deleteCookie() method there, then see my
signature. Did I mention that you should read what you reply to?


PointedEars

 

[Michael Winter]

2) Parse cookie string "foo", extract each separate cookie and
make it expired [...]

As I said, step 2 is not possible. Once in a while you should read
what you reply to.

What do you mean "impossible"?

Not possible.

How do you think all JavaScript cookie management systems work?

Thomas clearly has a greater understanding than you do, but that is
hardly a surprise, is it?

When a cookie is created, it is possible to specify path and domain
parameters to explicitly define the scope of that cookie. In order to
modify a particular cookie, this extra information needs to be resupplied.

Example:
Set-Cookie: name=value; expires=Tue, 14-Feb-2005 20:00:00 GMT;
path=/foo

Expected:
Cookie: name=value

Actual:
Cookie: name=value


Your suggestion:
Set-Cookie: name=value; expires=Thu, 01-Jan-1970 00:00:00 GMT

You expect:
<no Cookie header>

Actual:
Cookie: name=value

The two cookies do not match. The second Set-Cookie header (or
document.cookie property equivalent) effectively creates a second cookie
that has already expired.

If user agents implemented RFC 2965 (and I know of none that do), this
necessary information would be supplied in the Cookie request header,
along with the cookie values, and it could indeed be parsed out and used
for deletion.

Read some manual

Pot. Kettle. Black.

like
<http://www.netspade.com/articles/2005/11/16/javascript-cookies/>

That isn't a manual, and it doesn't support your assertions (quite the
opposite, in fact).

Mike

 

[VK]

VK wrote:

2) Parse cookie string "foo", extract each separate cookie and
make it expired [...]

As I said, step 2 is not possible. Once in a while you should read
what you reply to.

What do you mean "impossible"?

Not possible.

How do you think all JavaScript cookie management systems work?

Thomas clearly has a greater understanding than you do, but that is
hardly a surprise, is it?

Not really - specially as I'm getting more and more hard to be
surprised recently

Thomas doesn't have better understanding, but he's already getting what
attitude (atop of his regular one which may infect you if stay
regularly on clj.
Namely when someone is asking "I have situation A there I would like to
accomplish the action X" one doesn't think about the practical answer
first:- but she thinks first of situations B, C, ...Z where the action
X may fail or not possible or not blessed etc. That's should be the
secondary thinking one is welcome to place at the postscriptum of the
solution. And if you have no solution, then do not post at all (a
letter consisting of a postscriptum only is a rather strange thing).
It's all IMHighlyHO and off-topic.

Now reading OP's original question once over: "Any cookies that I have
associated with that site will be sent along with this HTTP request".
*I have associated*

From my (possibly wrong) reading of this sentence I concluded that OP

knows what cookies, for what domain and what path did he set.

name/domain/path exact match was implemented for exactly the opposite
situation: when someone wants to destroy cookie set by someone else.
Again it might be my mistake but I did not read this situation out of
the post.

 

[TerraFrost]

knows what cookies, for what domain and what path did he set.

That is indeed the case.

 

[yawnmoth]

That is indeed the case.

Grr... the previous poster was me. Google Groups (shame on me for
using it) had me logged in with my gmail account - not the account I
prefer using on usenet...

 

[VK]

Grr... the previous poster was me. Google Groups (shame on me for
using it) had me logged in with my gmail account - not the account I
prefer using on usenet...

For Google post: Show options > Remove

We shall pretend we've never seen the previous one :-D

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
VK wrote:
2) Parse cookie string "foo", extract each separate cookie and
make it expired [...]
As I said, step 2 is not possible. Once in a while you should read
what you reply to.
What do you mean "impossible"? Not possible.
How do you think all JavaScript cookie management systems work?

Thomas clearly has a greater understanding than you do, but that is
hardly a surprise, is it?

Not really - specially as I'm getting more and more hard to be
surprised recently

Thomas doesn't have better understanding, but he's already getting what
attitude (atop of his regular one which may infect you if stay
regularly on clj.
[...]

What are you babbling about again? Read it from my fingertips: It is _not
possible_ to delete all cookies that apply to a resource because either of
the cookies retrieved with document.cookies may be set for a domain of the
resource of a higher level (say a resource on bla.example.com reading the
cookie set for .example.com) or a path of a higher level (say a resource on
example.com/foo/bar/ to retrieve a cookie set for example.com/foo/) or a
combination of both. Then you have _no chance_ to set this cookie to
expire (read: to delete it) as you have no chance to retrieve that kind of
information and so you cannot set the exact domain or path component of the
string that needs to be assigned. And using the second-level domain of the
resource or the root path does not modify the corresponding cookie, so
cannot delete it.

Now reading OP's original question once over: "Any cookies that I have
associated with that site will be sent along with this HTTP request".
*I have associated*

A Web site usually consists of more than one resource.

From my (possibly wrong) reading of this sentence I concluded that OP
knows what cookies, for what domain and what path did he set.

Perhaps, perhaps not. For example, session cookies ("session" referring
to server-side sessions here, not necessarily also to client-side ones),
are often set/sent automatically by server-side applications.

name/domain/path exact match was implemented for exactly the opposite
situation: when someone wants to destroy cookie set by someone else.

Utter nonsense. It was implemented to allow cookies to be accessible
throughout a Web site, especially sub-level domains and subpaths, and
accessible in a sub-level domain (and its sub-level domains) and subpaths
but not in the domain or path of higher level.


PointedEars

 

[Michael Winter]

On 14/02/2006 20:59, VK wrote:

[snip]

Now reading OP's original question once over: "Any cookies that I have
associated with that site will be sent along with this HTTP request".
*I have associated*

From my (possibly wrong) reading of this sentence I concluded that OP
knows what cookies, for what domain and what path did he set.

One should certainly hope that, given a particular cookie, code that
deals with this cookie should know the conditions under which is was
created. However, if there were, for example, two cookies used across a
site, code that uses only one shouldn't need to know about the other.

What you proposed - removing and then restoring the cookies - would mean
that the client-side code would need to know everything about both, and
would need to be maintained in parallel to the code that creates and
uses them. Even then, the client-side code still may not be able to
restore the cookies properly as it will not know the original expiration
time and date.

name/domain/path exact match was implemented for exactly the opposite
situation: when someone wants to destroy cookie set by someone else.

Not at all. The domain and path parameters allow an application to
control where within a site the state information will apply (I already
said that). The required matching algorithm, insofar as matching name,
domain and path, is in place to ensure that the correct cookie is
modified as cookies with the same name can co-exist. It does have the
side-effect of making modification difficult unless the this data is
known, but it's not the reason (otherwise RFC 2965 wouldn't specify
behaviour that exposes it).

Again it might be my mistake but I did not read this situation out of
the post.

To be fair to you, it isn't your responsibility to try to infer
information about a situation that cannot reasonably be known: the OP
should make the circumstances clear. However, you cannot espouse
practicality and then go on to propose something that is clearly not
practical under a reasonable scenario.

Mike