You may also set array cookies by using array notation in the cookie name. This has the effect of setting as many cookies as you have array elements, but when the cookie is received by your script, the values are all placed in an array with the cookie’s name:
<?php
// set the cookies
setcookie("cookie[three]", "cookiethree");
setcookie("cookie[two]", "cookietwo");
setcookie("cookie[one]", "cookieone");
// after the page reloads, print them out
if (isset($_COOKIE['cookie'])) {
foreach ($_COOKIE['cookie'] as $name => $value) {
echo "$name : $value <br />\
";
}
}
?>
This has the advantage of having each value accessible as an array, but has the disadvantage (?) of setting one cookie for each value. This means you could end up with something like:
Sessions are a completely different thing altogther, and offer no answer to my best practice quesiton. A session is lost as soon as the visitor closes his or her browser, while a cookie will always be available on the next session. A session is kept server-side, while a cookie is kept on the client’s side.
Where I work, this is a very bad idea, though it depends on what you’re doing. Where I work we have dozens of different applications available for employees, and most employees use several of them.
Browsers have a limit on the number of cookies you can set for one domain and once you hit that, they start bumping cookies. So we try to really limit the number of cookies we set.
Im always amazed when seeing that people still try to stuff a lot of information into cookies. Doing so is a bad idea, cookies should only be used for information that has to be stored there example, session id.
The reason you should not “stuff” the information into cookies are due to a cookie is sent with every request to the server, it being a request for a webpage or an image etc. The more information the cookie contains, the larger will the upload be for each request, and with that the processing time on the server.
I disagree. If you run a website that has a million pageviews per day, keeping flags for things like a chosen theme, language, or other preferences in a cookie might be preferable above putting this in a database. Google does the same, it keeps all your preferences in a cookie. Except, they do it in an “equal-sign delimited” cookie, instead of the string-solution that I posted in post #1.
Just doing something due to someone else does it is not always a good idea if you do not understand why they do it.
Google stores two cookies if you use their search, but none of them contain huge amount of data. In addition their search page does not have that many images so the amount of requests is very low compared to most websites.
There is two main reasons google does this, one: they keep the visitors info stored without requireing them to login, two: making the replication easier.
If you use any of googles programs that require you to login you will see that they do not store the settings in cookies anymore.
If you want to go the cookie route, remember you can limit cookies to only be used at specific paths/subdomains so you can limit the overhead on most requests that dond need to forward the cookie info.
But garbage collection will still remove the session files from the server in under 30 minutes or however long their max lifetime is set to, where a cookie can last for years if the user doesn’t delete it.
json_encode() adds some control characters though.
I don’t see why you guys are even making such a huge deal of this. There was no indication that thumbthump was planning to store a lot of information in the cookie. If you carefully read his post, you would have noticed that he was only going to store a few things. He wasn’t following Google’s practice just because Google was doing it.
On the subject of the topic, it does not really matter because you’re not even close to approaching 4 KB. You would save some overhead though.
In the case of multiple cookies, the browser would send: