sending http requests without cookies

Discussion in 'Javascript' started by yawnmoth, Feb 14, 2006.

  1. yawnmoth

    yawnmoth Guest

    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','');
    yawnmoth, Feb 14, 2006
    #1
    1. Advertising

  2. yawnmoth

    VK Guest

    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? I
    > tried the following to no avail:
    >
    > http.setRequestHeader('Cookie','');


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

    ( ? )
    VK, Feb 14, 2006
    #2
    1. Advertising

  3. VK wrote:

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


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

    >> I tried the following to no avail:
    >>
    >> http.setRequestHeader('Cookie','');


    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
    Thomas 'PointedEars' Lahn, Feb 14, 2006
    #3
  4. yawnmoth

    VK Guest

    Thomas 'PointedEars' Lahn wrote:
    > VK wrote:
    >
    > > 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?

    >
    > I don't think so. Why would that be necessary anyway?
    >
    > >> I tried the following to no avail:
    > >>
    > >> http.setRequestHeader('Cookie','');

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


    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.
    VK, Feb 14, 2006
    #4
  5. VK wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> VK wrote:
    >> > 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
    Thomas 'PointedEars' Lahn, Feb 14, 2006
    #5
  6. yawnmoth

    VK Guest

    Thomas 'PointedEars' Lahn wrote:
    > > 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.


    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/>
    VK, Feb 14, 2006
    #6
  7. VK wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> > 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.

    >
    > 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
    --
    Learn to think clearly.
    Learn to distinguish: What is, and what seems to be.
    -- Surak
    Thomas 'PointedEars' Lahn, Feb 14, 2006
    #7
  8. On 14/02/2006 19:00, VK wrote:

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

    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

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
    Michael Winter, Feb 14, 2006
    #8
  9. yawnmoth

    VK Guest

    Michael Winter wrote:
    > On 14/02/2006 19:00, VK wrote:
    >
    > > 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.
    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.
    VK, Feb 14, 2006
    #9
  10. yawnmoth

    TerraFrost Guest

    VK wrote:
    > <snip>
    > >From my (possibly wrong) reading of this sentence I concluded that OP

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

    That is indeed the case.
    TerraFrost, Feb 14, 2006
    #10
  11. yawnmoth

    yawnmoth Guest

    TerraFrost wrote:
    > VK wrote:
    > > <snip>
    > > >From my (possibly wrong) reading of this sentence I concluded that OP

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

    > 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...
    yawnmoth, Feb 14, 2006
    #11
  12. yawnmoth

    VK Guest

    yawnmoth wrote:
    > 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
    VK, Feb 14, 2006
    #12
  13. VK wrote:

    > Michael Winter wrote:
    >> On 14/02/2006 19:00, VK wrote:
    >> > 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
    Thomas 'PointedEars' Lahn, Feb 14, 2006
    #13
  14. 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

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
    Michael Winter, Feb 15, 2006
    #14
    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. yawnmoth
    Replies:
    8
    Views:
    1,914
    yawnmoth
    Aug 21, 2006
  2. _Who
    Replies:
    7
    Views:
    2,652
  3. d c
    Replies:
    2
    Views:
    122
    Francis Cianfrocca
    Dec 24, 2007
  4. Yuchung Cheng

    Module of sending http 1.1 and/or 1.0 requests

    Yuchung Cheng, Jun 26, 2003, in forum: Perl Misc
    Replies:
    3
    Views:
    104
  5. Luca Cerone
    Replies:
    8
    Views:
    183
    Luca Cerone
    Aug 30, 2013
Loading...

Share This Page