Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #29933 > unrolled thread

Difference between client and server side cookie

Back to article view | Back to comp.lang.javascript

Contents

  Difference between client and server side cookie bit-naughty@hotmail.com - 2016-03-12 05:38 -0800
    Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-12 15:02 +0100
    Re: Difference between client and server side cookie Stefan Weiss <krewecherl@gmail.com> - 2016-03-12 16:19 +0100
      Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-12 23:32 +0100
        Re: Difference between client and server side cookie Aleksandro <aleksandro@gmx.com> - 2016-03-12 20:23 -0300
          Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-13 10:48 +0100
            Re: Difference between client and server side cookie Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-13 10:42 +0000
              Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-13 12:05 +0100
                Re: Difference between client and server side cookie Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-13 11:46 +0000
              Re: Difference between client and server side cookie Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-13 13:46 +0100
                Re: Difference between client and server side cookie bit-naughty@hotmail.com - 2016-03-13 07:07 -0700
                  Re: Difference between client and server side cookie Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-13 16:34 +0100
                Re: Difference between client and server side cookie Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-13 23:42 +0000
                  Re: Difference between client and server side cookie Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-14 01:54 +0100
                    Re: Difference between client and server side cookie Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-14 10:36 +0100
                  Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-14 11:43 +0100
                    Re: Difference between client and server side cookie Aleksandro <aleksandro@gmx.com> - 2016-03-14 10:21 -0300
                      Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-14 15:01 +0100
                        Re: Difference between client and server side cookie Aleksandro <aleksandro@gmx.com> - 2016-03-14 11:52 -0300
                          Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-14 17:06 +0100
                            Re: Difference between client and server side cookie Aleksandro <aleksandro@gmx.com> - 2016-03-14 13:17 -0300
                              Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-14 19:43 +0100
                                Re: Difference between client and server side cookie Aleksandro <aleksandro@gmx.com> - 2016-03-14 16:17 -0300
                                  Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-14 23:22 +0100
                                    Re: Difference between client and server side cookie Aleksandro <aleksandro@gmx.com> - 2016-03-14 19:38 -0300
                                      Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-14 23:44 +0100
                                        Re: Difference between client and server side cookie Aleksandro <aleksandro@gmx.com> - 2016-03-14 21:49 -0300
                                          Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-15 10:18 +0100
                                            Re: Difference between client and server side cookie Aleksandro <aleksandro@gmx.com> - 2016-03-15 11:39 -0300
                    Re: Difference between client and server side cookie John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-15 09:40 +0000
                      Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-15 12:08 +0100
                        Re: Difference between client and server side cookie Stefan Weiss <krewecherl@gmail.com> - 2016-03-15 13:22 +0100
                          Re: Difference between client and server side cookie "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-15 15:53 +0100
            Re: Difference between client and server side cookie Aleksandro <aleksandro@gmx.com> - 2016-03-13 13:51 -0300
      Re: Difference between client and server side cookie bit-naughty@hotmail.com - 2016-03-13 07:09 -0700

Page 1 of 2  [1] 2  Next page →

#29933 — Difference between client and server side cookie

Is there any difference between the 2, as in one set by JS on the browser side, and one set in PHP code running on the server? They both result in exactly the same thing happening, right? (ie. for PHP the required data just travels over HTTP to the browser, which then does whatever?)
If, for example I set "x=3" in a cookie in JS, can I then set "x=4" in PHP on the server side? Or even just check what "x" is? How?

Thanks for your help.

[toc] | [next] | [standalone]

#29936

bit-naughty@hotmail.com wrote on 12 Mar 2016 in comp.lang.javascript:

> Is there any difference between the 2, as in one set by JS on the
> browser side, and one set in PHP code running on the server? They both
> result in exactly the same thing happening, right? (ie. for PHP the
> required data just travels over HTTP to the browser, which then does
> whatever?) If, for example I set "x=3" in a cookie in JS, can I then set
> "x=4" in PHP on the server side? Or even just check what "x" is? How? 

Cookies are ALWAYS stored in clientside memory [= "on the browser"].

Cookies are key/value pairs used to store state informations on the browser. 
Say you have a website (example.com), when the browser requests a webpage 
the website can send cookies to store informations on the browser.

Cookies can be set by serverside code, such as ASP-Jscript, ASP-vbscript or 
PHP, by setting a HTTP headers. Cookies can also be set by clienside 
[Javascript] code.

Serverside session-variables are sometimes erroneously and foolishly called 
"serverside cookies". They are stored on the server.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29940

On 03/12/2016 14:38, bit-naughty@hotmail.com wrote:
> Is there any difference between the 2, as in one set by JS on the
> browser side, and one set in PHP code running on the server? They both
> result in exactly the same thing happening, right? (ie. for PHP the
> required data just travels over HTTP to the browser, which then does
> whatever?)

Normally, there is no difference. You can read and set cookies on the
server and on the client (with JS).
The situation changes when the cookie set by the server uses the
HttpOnly flag. If the browser supports this extension (and all major
browsers do), they will not let scripting languages read or change the
value of that cookie. See example below.

> If, for example I set "x=3" in a cookie in JS, can I then set "x=4"
> in PHP on the server side? Or even just check what "x" is? How?

Server-side code (PHP):

  setcookie("one",   "1");
  setcookie("two",   "2", 0, "", "", false, true);  // HttpOnly
  setcookie("three", "3");

HTTP response header:

  Set-Cookie: one=1
  Set-Cookie: two=2; httponly
  Set-Cookie: three=3

Client (JS):

  console.log(document.cookie);         // "one=1; three=3"

  document.cookie = "one=11";
  console.log(document.cookie);         // "one=11; three=3"

  document.cookie = "two=22";
  console.log(document.cookie);         // "one=11; three=3" (!!)

  document.cookie = "three=33";
  console.log(document.cookie);         // "one=11; three=33"

Next HTTP request header:

  Cookie: one=11; two=2; three=33

Server-side code (PHP):

  var_export($_COOKIE);

  // array (
  //   'one' => '11',
  //   'two' => '2',
  //   'three' => '33',
  // )


Note that the client was unable to see or modify the value of the "two"
cookie because it was protected by the HttpOnly flag.


- stefan

[toc] | [prev] | [next] | [standalone]

#29946

Stefan Weiss <krewecherl@gmail.com> wrote on 12 Mar 2016 in 
comp.lang.javascript:

> Normally, there is no difference. You can read and set cookies on the
> server and on the client (with JS).

There are no cookies "on the server".

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29948

On 12/03/16 19:32, Evertjan. wrote:
> Stefan Weiss <krewecherl@gmail.com> wrote on 12 Mar 2016 in 
> comp.lang.javascript:
> 
>> Normally, there is no difference. You can read and set cookies on the
>> server and on the client (with JS).
> 
> There are no cookies "on the server".

There are while I am taking care of a request that sent them.

[toc] | [prev] | [next] | [standalone]

#29952

Aleksandro <aleksandro@gmx.com> wrote on 13 Mar 2016 in 
comp.lang.javascript:

> On 12/03/16 19:32, Evertjan. wrote:
>> Stefan Weiss <krewecherl@gmail.com> wrote on 12 Mar 2016 in 
>> comp.lang.javascript:
>> 
>>> Normally, there is no difference. You can read and set cookies on the
>>> server and on the client (with JS).
>> 
>> There are no cookies "on the server".
> 
> There are while I am taking care of a request that sent them.

Take care, that is nonsense.

I even don't understand your sentense.



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29955

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

> Aleksandro <aleksandro@gmx.com> wrote on 13 Mar 2016 in 
> comp.lang.javascript:
>
>> On 12/03/16 19:32, Evertjan. wrote:
>>> Stefan Weiss <krewecherl@gmail.com> wrote on 12 Mar 2016 in 
>>> comp.lang.javascript:
>>> 
>>>> Normally, there is no difference. You can read and set cookies on the
>>>> server and on the client (with JS).
>>> 
>>> There are no cookies "on the server".
>> 
>> There are while I am taking care of a request that sent them.
>
> Take care, that is nonsense.
>
> I even don't understand your sentense.

He's saying that there are sometimes cookies "on the server" --
specifically they are sent there every time a client makes a request for
which a cookie is relevant.  Where are they while the server is using
them if not "on the server"?  It's a small point, but it's not wrong.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29956

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 13 Mar 2016 in 
comp.lang.javascript:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
> 
>> Aleksandro <aleksandro@gmx.com> wrote on 13 Mar 2016 in 
>> comp.lang.javascript:
>>
>>> On 12/03/16 19:32, Evertjan. wrote:
>>>> Stefan Weiss <krewecherl@gmail.com> wrote on 12 Mar 2016 in 
>>>> comp.lang.javascript:
>>>> 
>>>>> Normally, there is no difference. You can read and set cookies on the
>>>>> server and on the client (with JS).
>>>> 
>>>> There are no cookies "on the server".
>>> 
>>> There are while I am taking care of a request that sent them.
>>
>> Take care, that is nonsense.
>>
>> I even don't understand your sentense.
> 
> He's saying that there are sometimes cookies "on the server" --
> specifically they are sent there every time a client makes a request for
> which a cookie is relevant.  Where are they while the server is using
> them if not "on the server"?  It's a small point, but it's not wrong.

No, not "are", cookies only exist where they are stored, and they are stored 
only in client/browser memory.

A request for setting a cookie or a response on reading a cookie is not a 
cookie, as then the key/value-combination can and will even be on an 
intermediate internet server or in your router memory for a moment, but I 
consider that not "are" in the sense of "existing".

<% session.cookie("myKey") = "myvalue"; %> [ASP-Jscript]

IS NOT a cookie, but a serverside command to set the http-header for making 
a cookie in the browser. The cookie only comes into existence whn it is 
created by the browser in it's memory.

> Where are they while the server is using
> them if not "on the server"? 

No, the server is using ONLY the content of the cookie, the key/value pair.

If the value of a cookie is 2, multiplying that value with 3 is not 
multiplying the cookie with 3.



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29958

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 13 Mar 2016 in 
> comp.lang.javascript:
>
>> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>> 
>>> Aleksandro <aleksandro@gmx.com> wrote on 13 Mar 2016 in 
>>> comp.lang.javascript:
>>>
>>>> On 12/03/16 19:32, Evertjan. wrote:
>>>>> Stefan Weiss <krewecherl@gmail.com> wrote on 12 Mar 2016 in 
>>>>> comp.lang.javascript:
>>>>> 
>>>>>> Normally, there is no difference. You can read and set cookies on the
>>>>>> server and on the client (with JS).
>>>>> 
>>>>> There are no cookies "on the server".
>>>> 
>>>> There are while I am taking care of a request that sent them.
>>>
>>> Take care, that is nonsense.
>>>
>>> I even don't understand your sentense.
>> 
>> He's saying that there are sometimes cookies "on the server" --
>> specifically they are sent there every time a client makes a request for
>> which a cookie is relevant.  Where are they while the server is using
>> them if not "on the server"?  It's a small point, but it's not wrong.
>
> No, not "are", cookies only exist where they are stored, and they are stored 
> only in client/browser memory.

The data are stored in both places.  You are in fact stipulating that
it's not a cookie (in your terms) either in transit or when it is stored
on the server.

> A request for setting a cookie or a response on reading a cookie is not a 
> cookie, as then the key/value-combination can and will even be on an 
> intermediate internet server or in your router memory for a moment, but I 
> consider that not "are" in the sense of "existing".

OK.  That's one point of view but then you can't say things like "a
cookie is sent to the server in the HTTP request header".  The cookie
ceases to be a cookie once in transmission.  I think that just
complicates the way have to talk about these things.

<snip>
>> Where are they while the server is using
>> them if not "on the server"? 
>
> No, the server is using ONLY the content of the cookie, the key/value
> pair.

I think that's unnecessarily fussy and does not match the usage in the
RFCs.  They refer to "sending cookies" and the one specifically about
cookies defines them as a name/value pairs that are passed to the user
agent and returned to the server.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29959

Ben Bacarisse wrote:

> He's saying that there are sometimes cookies "on the server" --
> specifically they are sent there every time a client makes a request for
> which a cookie is relevant.

In fact, only cookie *names* and *values* are sent with every HTTP request 
that applies to their “domain”, “path” and “secure” attributes, unless they 
have expired (as specified by the “expires” attribute in a former HTTP 
response header “Set-Cookie” field value or in the value assigned to the 
document.cookie property).

> Where are they while the server is using them if not "on the server"?

Still stored on the client machine.  Cookies are data (stored in local 
files) only whose *names* and *values* are incorporated into a HTTP request 
header “Cookie” field value.

> It's a small point, but it's not wrong.

Yes, it is.

<https://en.wikipedia.org/wiki/HTTP_cookie#Implementation>
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29961

Evertjan is right.

[toc] | [prev] | [next] | [standalone]

#29963

bit-naughty@hotmail.com wrote:

> Evertjan is right.

By virtue of you saying so?

What is the point of your posting?  And when will you learn to post?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29970

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> He's saying that there are sometimes cookies "on the server" --
>> specifically they are sent there every time a client makes a request for
>> which a cookie is relevant.
>
> In fact, only cookie *names* and *values* are sent with every HTTP request 
> that applies to their “domain”, “path” and “secure” attributes, unless they 
> have expired (as specified by the “expires” attribute in a former HTTP 
> response header “Set-Cookie” field value or in the value assigned to the 
> document.cookie property).
>
>> Where are they while the server is using them if not "on the server"?
>
> Still stored on the client machine.

And on the server while the server is processing the request.

> Cookies are data (stored in local 
> files) only whose *names* and *values* are incorporated into a HTTP request 
> header “Cookie” field value.

But it is not a cookie only when in some client's store.  The RFC (6265)
defines a cookie as a name/value pair and it is still a cookie as that
name/value pair is sent over the wire.  This is clear from the language
the RFC uses:

  "The semantics of individual cookies in the Cookie header are not
  defined"

  "if the Cookie header contains two cookies with the same name"

  "if the user agent fails to return one or more cookies in the Cookie
  header"

  "The active network attacker can intercept these cookies"

  "the user agent will include that cookie in HTTP requests"

and so on.  It is perfectly reasonable to talk of the cookie in transit,
in the header and arriving (to be stored however temporarily) on the
server.

>> It's a small point, but it's not wrong.
>
> Yes, it is.
>
> <https://en.wikipedia.org/wiki/HTTP_cookie#Implementation>

The RFC is definitive.  If this Wikipedia article contradicts it,
Wikipedia needs to be corrected.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29971

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> He's saying that there are sometimes cookies "on the server" --
>>> specifically they are sent there every time a client makes a request for
>>> which a cookie is relevant.
>>
>> In fact, only cookie *names* and *values* are sent with every HTTP
>> request that applies to their “domain”, “path” and “secure” attributes,
>> unless they have expired (as specified by the “expires” attribute in a
>> former HTTP response header “Set-Cookie” field value or in the value
>> assigned to the document.cookie property).
>>
>>> Where are they while the server is using them if not "on the server"?
>>
>> Still stored on the client machine.
> 
> And on the server while the server is processing the request.

Nonsense.

>> Cookies are data (stored in local files) only whose *names* and *values* 
>> are incorporated into a HTTP request header “Cookie” field value.
> 
> But it is not a cookie only when in some client's store.

Yes, it is.

> The RFC (6265) defines a cookie as a name/value pair

No, it does not:

| 4.2.2.  Semantics
| 
|    Each cookie-pair represents a cookie stored by the user agent.  The
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|    cookie-pair contains the cookie-name and cookie-value the user agent
|    received in the Set-Cookie header.
| 
|    Notice that the cookie attributes are not returned. […]

> and it is still a cookie as that name/value pair is sent over the wire. 

No, it is not.  A representation is _not_ the real thing.  Like in 
ECMAScript where a string representation of an object is _not_ the object 
itself.

> This is clear from the language the RFC uses:

Your interpretation is not supported by that RFC; in fact, it is refuted by 
that.
 
>   "The semantics of individual cookies in the Cookie header are not
>   defined"
> 
>   "if the Cookie header contains two cookies with the same name"
> 
>   "if the user agent fails to return one or more cookies in the Cookie
>   header"

By the RFCs own definition, the Cookie header (field) value is _not_ a 
cookie, too.  It is a comma-separated list of cookie name-value pairs 
(“cookie-pairs”) sent by the client to the server.  The RFC is
contradicting itself here partially, due to imprecise wording.
 
>   "The active network attacker can intercept these cookies"
> 
>   "the user agent will include that cookie in HTTP requests"

Fallacy: Straw man.  The first phrase is referring to the information sent 
from the server to the client, not vice-versa, as the value of each
“Set-Cookie” *response* header field does constitute a cookie on the client
*if it is stored there*.  As for the second phrase, see above.

> and so on.

Fallacy: Hasty generalization.

> It is perfectly reasonable to talk of the cookie in transit,
> in the header and arriving (to be stored however temporarily) on the
> server.

No, it is not.
 
>>> It's a small point, but it's not wrong.
>>
>> Yes, it is.
>>
>> <https://en.wikipedia.org/wiki/HTTP_cookie#Implementation>
> 
> The RFC is definitive.  If this Wikipedia article contradicts it,
> Wikipedia needs to be corrected.

You are, in the best case, misinterpreting the RFC (which is only a 
*Proposed* Standard now, so in no way definitive; see RFC 2026, §4.4.1) 
completely.  In the worst case, you are quoting from it selectively 
deliberately in order to support your opinion.  Fallacy: Cherry picking.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29977

Thomas 'PointedEars' Lahn wrote:

> By the RFCs own definition, the Cookie header (field) value is _not_ a
> cookie, too.  It is a comma-separated list of cookie name-value pairs

_semicolon_-separated

> (“cookie-pairs”) sent by the client to the server.  The RFC is
> contradicting itself here partially, due to imprecise wording.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29978

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 14 Mar 2016 in 
comp.lang.javascript:

>  It is perfectly reasonable to talk of the cookie in transit,
> in the header and arriving (to be stored however temporarily) on the
> server.

Indeed, so I reason against it.

For then you should concede that a cookie can also "however temporarily" 
exists on your router, on all the hosts seen by traceroute in transit to and 
from the server. 

No, I "perfectly reasonably" reason it makes no sense to call that 
"existing".

No, I reason that only the content [key/value/expiration-info] of a cookie 
travels with of in response to commands, but that the cookie "is" what is 
stored in browser-memory. 

btw, you would not call a command to delete a cookie [key + past date] a 
cookie, I trust? 

And what about a command to change an existing [in my definition] cookie's 
value, would that be a "traveling" cookie in its own right? Not so!

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29982

On 14/03/16 07:43, Evertjan. wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 14 Mar 2016 in 
> comp.lang.javascript:
> 
>>  It is perfectly reasonable to talk of the cookie in transit,
>> in the header and arriving (to be stored however temporarily) on the
>> server.
> 
> Indeed, so I reason against it.
> 
> For then you should concede that a cookie can also "however temporarily" 
> exists on your router, on all the hosts seen by traceroute in transit to and 
> from the server. 
> 
> No, I "perfectly reasonably" reason it makes no sense to call that 
> "existing".
> 
> No, I reason that only the content [key/value/expiration-info] of a cookie 
> travels with of in response to commands, but that the cookie "is" what is 
> stored in browser-memory. 
> 
> btw, you would not call a command to delete a cookie [key + past date] a 
> cookie, I trust? 
> 
> And what about a command to change an existing [in my definition] cookie's 
> value, would that be a "traveling" cookie in its own right? Not so!

Let's make an analogy here.

Your eyes are organ that exist inside your skull and let you see. If I
take them off with a spoon, they cease being eyes because they are
outside now and you can't see anymore?

[toc] | [prev] | [next] | [standalone]

#29983

Aleksandro <aleksandro@gmx.com> wrote on 14 Mar 2016 in
comp.lang.javascript: 

> On 14/03/16 07:43, Evertjan. wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 14 Mar 2016 in 
>> comp.lang.javascript:
>> 
>>>  It is perfectly reasonable to talk of the cookie in transit,
>>> in the header and arriving (to be stored however temporarily) on the
>>> server.
>> 
>> Indeed, so I reason against it.
>> 
>> For then you should concede that a cookie can also "however
>> temporarily" exists on your router, on all the hosts seen by traceroute
>> in transit to and from the server. 
>> 
>> No, I "perfectly reasonably" reason it makes no sense to call that 
>> "existing".
>> 
>> No, I reason that only the content [key/value/expiration-info] of a
>> cookie travels with of in response to commands, but that the cookie
>> "is" what is stored in browser-memory. 
>> 
>> btw, you would not call a command to delete a cookie [key + past date]
>> a cookie, I trust? 
>> 
>> And what about a command to change an existing [in my definition]
>> cookie's value, would that be a "traveling" cookie in its own right?
>> Not so! 
> 
> Let's make an analogy here.
> 
> Your eyes are organ that exist inside your skull and let you see. If I
> take them off with a spoon, they cease being eyes because they are
> outside now and you can't see anymore?

Nonsense, eyes don't store data, dead eyes even less than not.

A cookie is a data-container, 
an instance of preserving such data,
not the data itself.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29984

On 14/03/16 11:01, Evertjan. wrote:
> Aleksandro <aleksandro@gmx.com> wrote on 14 Mar 2016 in
> comp.lang.javascript: 
> 
>> On 14/03/16 07:43, Evertjan. wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 14 Mar 2016 in 
>>> comp.lang.javascript:
>>>
>>>>  It is perfectly reasonable to talk of the cookie in transit,
>>>> in the header and arriving (to be stored however temporarily) on the
>>>> server.
>>>
>>> Indeed, so I reason against it.
>>>
>>> For then you should concede that a cookie can also "however
>>> temporarily" exists on your router, on all the hosts seen by traceroute
>>> in transit to and from the server. 
>>>
>>> No, I "perfectly reasonably" reason it makes no sense to call that 
>>> "existing".
>>>
>>> No, I reason that only the content [key/value/expiration-info] of a
>>> cookie travels with of in response to commands, but that the cookie
>>> "is" what is stored in browser-memory. 
>>>
>>> btw, you would not call a command to delete a cookie [key + past date]
>>> a cookie, I trust? 
>>>
>>> And what about a command to change an existing [in my definition]
>>> cookie's value, would that be a "traveling" cookie in its own right?
>>> Not so! 
>>
>> Let's make an analogy here.
>>
>> Your eyes are organ that exist inside your skull and let you see. If I
>> take them off with a spoon, they cease being eyes because they are
>> outside now and you can't see anymore?
> 
> Nonsense, eyes don't store data, dead eyes even less than not.
> 
> A cookie is a data-container, 
> an instance of preserving such data,
> not the data itself.

Well, they have been contained in plain text, now some browsers use
SQLite. Isn't the term affected by what contains them?

Isn't in-transit data still contained anyway?

[toc] | [prev] | [next] | [standalone]

#29985

Aleksandro <aleksandro@gmx.com> wrote on 14 Mar 2016 in 
comp.lang.javascript:

>>> Your eyes are organ that exist inside your skull and let you see. If I
>>> take them off with a spoon, they cease being eyes because they are
>>> outside now and you can't see anymore?
>> 
>> Nonsense, eyes don't store data, dead eyes even less than not.
>> 
>> A cookie is a data-container, 
>> an instance of preserving such data,
>> not the data itself.
> 
> Well, they have been contained in plain text,

So?

> now some browsers use
> SQLite. Isn't the term affected by what contains them?

No. 

They "exist" because they are "stored" not because of "how" they are stored.

> Isn't in-transit data still contained anyway?

Not a valid argument, containment has nothing to do with it, otherwise they 
could exist when still in the mind of the programmer. 



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web