PHP - Cookies (Yumm!)

[flame_211]

The basic idea behind cookies is very simple. The site stores a little bit of info on the users computer, which can be accessed at a later point in time. The info stored can be anything, but usually consists of the users username, password, etc. for that particular site.

// basic syntax
setcookie("stuff to store", $variable, "expiration date");

//example, expires 1 year after the cookie is stored
setcookie("stuff", $var1, time()+31104000);

//to retrieve cookie
$var1 = $_COOKIE['var1']; 

Any questions/comments, please feel free to contact me.

[visualAd]

Its worth noting that the cookie is not available in the $_COOKIE array until the next request. Also that this cookie will be available to all PHP scripts within the domain and the URI passed as the path parameter to the setcookie() function.

See here for more information.

[Slyke]

Why is it that JavaScript can set cookies when ever it wants to, but in PHP you must set cookies before sending any of the content?

[Kasracer]

Why is it that JavaScript can set cookies when ever it wants to, but in PHP you must set cookies before sending any of the content?

JavaScript is a client-side technology. PHP is a server-side technology. Cookies are a client-side object therefore JavaScript can access, add and manipulate cookies in real time because it's happening in real time. PHP, on the other hand, renders, requests and shows nothing to the browser until it sends its response. Therefore you have to setup your cookies before you send them otherwise how could they ever get set?

[Slyke]

Mmm, that is true, but I'm sure it's possible for PHP to make it so that it could send new cookies to the browser in real time (IE Real time means as the page is being sent, not 20 seconds after it's completed). I know that the HTTP protocol would have to be restructured and all that for this to happen, but I'm just a little unsure of why they wouldn't of designed it like that in the first place.

[Kasracer]

Mmm, that is true, but I'm sure it's possible for PHP to make it so that it could send new cookies to the browser in real time (IE Real time means as the page is being sent, not 20 seconds after it's completed). I know that the HTTP protocol would have to be restructured and all that for this to happen, but I'm just a little unsure of why they wouldn't of designed it like that in the first place.

When you say real time and when the page is being sent... well that's kind of what happens today. The cookies are sent with the page. If by "real time" you mean whenever the server decides to send cookies... then that's a bad idea. If that's the case not only are you opening a second connection to the user (otherwise you'd throw "real time" out the window and you'd have today's implementation) but the browser wouldn't have any guarantee that the cookies it's receiving came from the same site it requested data from. If you sent a cookie to the browser in "real time", what happens if the browsers requests a page slightly after your cookie? Your server won't realize the browser even has the cookie you sent so you better hope it's not important.

Today everything is sent at once. The browsers knows for sure that the cookies were set by the website it's loading. The server knows that the cookie will exist on the next request and everyone is happy.

I don't see why the way it's done today would be a problem anyway with any server-side of client-side technology. Cookies work fine in PHP; just don't set them after you start sending data back.

[techgnome]

Cookies have to be send before any output is rendered because they are part of the page header information that needs to be send to the client browser. Once you start sending the actual page data & displaying data, you can't re-modify the header info. Therefore, the cookies must be sent ahead of the page data.

-tg