Cookies best practice: using array notation with PHP's setcookie -- good or bad?

From the PHP manual entry for “setcookie”:

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:

// 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:

mycookie[theme] = “1”
mycookie[default_sort] = “date”
mycookie[first_visit] = “0”
mycookie[comment_name] = “UserEight”
mycookie[comment_email] = “

Etc… You can see this would result in 10 different cookies, while you normaly had one cookie, with pipe-seperated values for instance.

Or is it no problem to have this many cookies?

You would be far better suited to storing these values in a session, it allows you store beyond a cookies 4kb limit.

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.

A session is persisted by a cookie client side, you can set PHP to have this cookie persist past browser closure.

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.

So, in an attempt to answer my own question, this would be preffered in the case of my example in post #1?

Instead of…

mycookie[theme] = "1"
mycookie[default_sort] = "date"
mycookie[first_visit] = "0"
mycookie[comment_name] = "UserEight"
mycookie[comment_email] = ""

…i would be better off doing…

mycookie = "t=1|ds=date|fv=0|cn=UserEight|"

(In this example-case I have no way to store this data on a server-side database.)

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.

Very true Dan, good point.

My issue with storing data in a cookie is the 4kb limitation, more so using array notation due to the additional characters needed.

json_encode() could be a nice alternative to using a pipe char delimiter.

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:

Cookie: mycookie[theme]= 1; mycookie[default_sort]=date; mycookie[first_visit]=0; mycookie[comment_name]=UserEight; mycookie[comment_email]

(there would be some escaping)
But if you have one:

Cookie: mycookie=t=1|ds=date|fv=0|cn=UserEight|

(there would be escaping of the equal signs and such)