How does PHP know cookies set by JavaScript?

[Aeonix]

It might be obvious, but I can't seem to understand it. So don't laugh.

Let's assume this scenario. My website has 5 themes, there are 5 buttons. Clicking each button changes theme respectively and uniquely. I use JavaScript to do that, so I set name of theme in a cookie, for example theme=DarkOne and set it to expire over 10 years. My very local storage, saves that variable. Without knowledge of the server.

Visitor of my website decides to change his theme to theme=DarkOne by clicking one of buttons. Then, goes off wondering visiting of the wonderful images and very informative, stuff... meanwhile reloading the address (by going to various sub-pages) about 80 times.

Then decides to scroll down the website, takes glance at the footer and notices You're visiting our website using: DarkOne. Issued by $_COOKIE["theme"] from server-side PHP, my question is. How does the server know what the variable is set as? The JavaScript saved my variable on my personal local storage. PHP has never known my variables or any interaction with cookies.

Does Apache server request list of my cookies? I've been Googling the example HTTP requests, and have visited websites which show requests I send. But none of that appears on the request.

I realize that there's a thing called "cache". But it's content doesn't appear in HTTP headers.

Could someone shine some more light on this please?

No code can be provided, this isn't an error, nor malfunction. I'm just wondering how it works. And how it's possible.

[diafol]

localStorage is not the same as cookies. Cookies (HTTP cookies) whether set by js or php or anything else, should be readable. You've obviously read the manual:

PHP transparently supports HTTP cookies. Cookies are a mechanism for storing data in the remote browser and thus tracking or identifying return users. You can set cookies using the setcookie() or setrawcookie() function. Cookies are part of the HTTP header, so setcookie() must be called before any output is sent to the browser. This is the same limitation that header() has. You can use the output buffering functions to delay the script output until you have decided whether or not to set any cookies or send any headers.

and

Any cookies sent to you from the client will automatically be included into a $_COOKIE auto-global array if variables_order contains "C". If you wish to assign multiple values to a single cookie, just add [] to the cookie name.

[Aeonix]

localStorage is not the same as cookies

But the quote you pointed out said:

[...] Cookies are a mechanism for storing data in the remote browser and thus tracking or identifying return users. [...]

Isn't "remote browser" part of my "local storage"? Don't I write cookies created by JavaScript into my local temporal storage? If positive, how does PHP access them? If negative, where are they written? Is it a plain variable stuck in browser? string[] cookies = {"", ""}; ?

-----

[...]Cookies are part of the HTTP header[...]

I didn't notice any! Maybe because:

PHP transparently supports HTTP cookies[...]

But then, how it's done? Do I send all the cookies I have for this website, to the PHP per header? It's not like server is saying "send me your username". It needs entire cookie reference to parse at once without interruptions. Wouldn't that create A LOT of security holes? What if I'm malicious user, and I put up 1TB of fake cookies?

[diafol]

Have a look at this article about differences between localstorage/sessionstorage and cookies.

http://stackoverflow.com/questions/19867599/what-is-the-difference-between-localstorage-sessionstorage-session-and-cookies

OK, I'll try to take out some key points. localStorage is like a mini local DB to be read by the client (js; but not the server), unless that is you send that data purposely, e.g. via Ajax or form or url etc. Cookies on the other hand are meant to be read by the server as they are sent with all HTTP requests from the client to the server.

As you are aware, HTTP cookies can be written by js or php (and others). So cookies written via PHP can be read and modified by JS and vice-versa. However, if you set the HTTPOnly flag when creating/modifying them in PHP, then the client can't modify them.

In addition, you're probably aware too that js, being the interactive beauty it is, can read/update/read again/update again as it sees fit. PHP however once it writes a cookie, it can't read it until the next round trip to the server as it has to be sent via HTTP header to be in the $_COOKIE superglobal. That's an over-simplification, I know, but that's the gist of it AFAIK.

[Aeonix]

That's an over-simplification, I know, but that's the gist of it AFAIK.

It's over-simplified!?!?!

localStorage is like a mini local DB to be read by the client (js; but not the server), unless that is you send that data purposely, e.g. via Ajax or form or url etc. [...] Cookies on the other hand are meant to be read by the server as they are sent with all HTTP requests from the client to the server.

If cookies are meant to be read by servers, and the localStorage is a mini database that can be read by client (using JavaScript in this case). What happens if I issue document.cookie="username=John Doe; expires=Thu, 18 Dec 2020 12:00:00 UTC"? That string is thus written in my localStorage, how does PHP get to know about it (and it's value)?

Cookies on the other hand are meant to be read by the server as they are sent with all HTTP requests from the client to the server

But how do I know, which cookies to serve it, without my browser knowing the PHP code? It can't read the file, it doesn't know that server has echo $_COOKIE["themes"] in their files. And PHP doesn't send "in-between" requests with "hey, pass me "themes" cookie".

JavaScript isn't being parsed. It's more like a manual, nobody cares what's inside, but it's supposed to be attached (according to HTML/PHP). Servers don't read these files. It couldn't possibly gather from it what's the value of it. Once I get my hands on .js file. My browser executes it, nobody else.

It longer it goes on, the harder it gets. Huehuehuehue >:D. Seriously though, I know it must be hard to explain it to someone like me, but bare with me please, I'd like to know it.

[diafol]

document.cookie="username=John Doe; expires=Thu, 18 Dec 2020 12:00:00 UTC"

is not stored to localStorage, it's written as a cookie. localStorage has no expiry - it's permanent - well until the user (or the application) deletes it. Because it's a cookie, it is sent with HTTP request. If it was in localStorage, it wouldn't be. You can store data traditionally stored in cookies in localStorage of course, but the appropriateness of this would depend upon the nature / purpose of this data.

The localStorage works something like this:

//Store
localStorage.setItem("handle", "diafol");
//Extract
document.getElementById("myHandle").innerHTML = localStorage.getItem("handle");

The server is completely oblivious to its existence, unless you pass that data to it purposely. Cookies are sent automatically (or "transparently").

Examples are a bit awkward without a context, but say as an user of Site X, you applied some settings like hide elements X,Y,Z of a jQuery widget. You wouldn't necessarily have to store this in a cookie - it would be a bit messy having to include js code inside php or vice-versa (although you could read the cookie via js - so would be easy actually thinking about it - but not sure what advantage a cookie would have). So, you could query the localStorage for these settings (if they exist) and apply them to your js code. Voila, all nice and easy without the server having to get bogged down in the finicky stuff.

I'm sure you can think of a better example, but I've had 30 cups of coffee and I'm still flagging!

You will find many examples of localStorage vs cookie on the WWW - some are good, some are bad and some are just plain wrong. I'd wager that some senior posters on here would have their own take of this, possibly different to mine.

[diafol]

Wrt theme (style??) - maybe best for COOKIE, since head files are requested as page loads. A localStorage item would have to be called and applied to choosing a style after a default was chosen? Not sure how you are doing this, so difficult to suggest.

[invisal]

It is better to understand how the HTTP Cookie works.

When your browser open a website, you send a HTTP request to the server. The HTTP request looks like this.

GET /index.php HTTP/1.1
Host: www.example.org

The request message tell server that you are requesting www.example.org (in case, a single server hosts multiple domain, telling which domain to access will help server decide which content to serve) and tell which page you want to request.

HTTP/1.1 200 OK
Content-Length: 17
Content-type: text/html
Set-Cookie: some_cookie=some_value

HTML Content HERE

The server will response back HTTP/1.1 200 OK that's mean the page you are trying to request exists. Optionally, the server may send Set-Cookie: .... to tell browser that you need to store the following cookie value into your browser for this domain.

The NEXT TIME, the browser request again to any page of this domain, it will send the whole cookie to the server.

GET /test.php HTTP/1.1
Host: www.example.org
Cookie: some_cookie=some_value

Browser HAVE obilgation to send all the cookie to the server, but browser does not have obilgation to send localStorage information to server. The rule of thumb is that if data that you want to set is not neccessary important for server to have it, store it in localStorage because have too much cookie consume unneccessary bandwidth.

Interestingly, when you use session_start(), the PHP will attempt to read if browser has session id in the cookie, if there is no session id in the cookie, it will generate a new session id and pass it to browser. The data of the SESSION will be stored in the file (you can override its behavior to store it in any storage you want, but by default, it stores in file).

[jkon]

Diafol and invisal gave the answer but I have never thought that the term “local storage” could be applied to cookies , in that sense Aeonix has any reason to ask how cookies are differentiating , the storage of those are local as anyone can notice , but we don't refer them as “local storage”.

@see https://developer.mozilla.org/en/docs/Web/API/Window/localStorage

Only cookies (of those methods) are by default set in the header of each request. So your server can get those informations (even if you created that cookie through JS) and when it responds (as invisal gave an example) it can alter or even create new ones. Would be very useful to use a tool like developer tools in Chrome (or like Firebug without the bugs …) to actually see what you are sending to server and what the server responds.

[Aeonix]

The server will response back HTTP/1.1 200 OK that's mean the page you are trying to request exists. Optionally, the server may send Set-Cookie: .... to tell browser that you need to store the following cookie value into your browser for this domain.

Solution. So it IS send per request.