2

can anyone confirm the behavior of PHP's setcookie() function when the client has cookies disabled? According to the documentation:

"If output exists prior to calling this function, setcookie() will fail and return FALSE. If setcookie() successfully runs, it will return TRUE. This does not indicate whether the user accepted the cookie."

I'm not sure what 'successfully runs' means exactly, but this leads me to believe that the implementation doesn't care about whether the client accepts the cookie, and that we shouldn't have to worry about PHP errors / warnings related to the cookie actually being set or not. Is that right?

Thanks in advance

anthonygiuliano
  • 197
  • 7
  • 2
    Did you bother to just give it a try, it does not seem like a difficult thing to set up a quick test for. When you find out post an anaswer for yourself and others – RiggsFolly Aug 25 '16 at 14:49
  • No, I'm not on a machine I can rig to run PHP right now and figured someone would know this off the top of the head. I'll update it later if there's no answer but I think it's already gotten some good ones. Thanks! – anthonygiuliano Aug 25 '16 at 14:59
  • How do you keep track of the fact that you sent a cookie and didn't get it back. Compared with this is a new session? PHP cannot tell the difference? – Ryan Vincent Aug 25 '16 at 19:19
  • @RyanVincent I believe the only way to know is by checking that it's there in a subsequent request. – anthonygiuliano Aug 26 '16 at 17:30

3 Answers3

5

Cookies are sent via http header. Headers can ALWAYS be sent. Whether they're accepted/ignored is irrelevant - you can send ANY header you want.

The only way to tell if a client has accepted a cookie is if the cookie gets sent BACK to the server by the client on its NEXT request.

The only way setcookie() fails is if output has already started. That causes the PHP "headers already sent" warning.

e.g. A normal HTTP server->client response looks like this:

HTTP/1.1 200 OK
Content-type: text/html
Cookie: ...cookie data here ...

<html><body>Hi mom!</body></html>

But if you do output first, BEFORE calling setcookie, you'd end up with something like this:

HTTP/1.1 200 OK
Content-type: text/html

<html><body>Hi mom!</body></html>
Cookie: ... cookie data here ...

which doesn't work. Headers are only headers when they're in the header block of the response. If they show up in the body, they're not a header - they're part of the content. That's why PHP issues the "headers already sent", and doesn't send the cookie. It can't - the train has already left the station.

Marc B
  • 356,200
  • 43
  • 426
  • 500
  • How do you distinguish between new users and users with disabled cookies? – gre_gor Aug 25 '16 at 14:56
  • 1
    You can't. HTTP is stateless. Every request is completely independent of every other request. That's why there's cookies - to have at least one piece of "constant" data going between the client and server to serve as a unique identifier. There is absolutely **NO** way to tell the difference between "new user who's never been here and therefore has no cookie" and "old user with cookies disable", or even "old user who deleted/cleared cookies". – Marc B Aug 25 '16 at 14:57
  • That being said, there are these days shifty/underhanded/evil ways of detecting previous users, but they're not easy, and require client-side scripting, e.g. so called "super cookies". – Marc B Aug 25 '16 at 14:59
  • Hm, yes I understand that. I just misunderstood where you said about detecting it on your second request. You are only talking about knowing if the cookie was accepted not if it was accepted **or** not. – gre_gor Aug 25 '16 at 15:06
3

No. setcookie() passes a Set-Cookie HTTP header to the webserver, which in turn transfers it to the client.

  • Any warning pertaining to the header is an issue of your code structure. See also: How to fix "Headers already sent" error in PHP

  • The result code of setcookie() does not indicate if the client honors the Set-Cookie HTTP header however. Because neither PHP nor the webserver knows.

Community
  • 1
  • 1
mario
  • 144,265
  • 20
  • 237
  • 291
2

Quite correct, the server cannot detect the clients settings, you should verify this with your own implementation.

If you send a cookie upon first request, checking if it exists on the next request. Then you would know if the client excepts cookies or not. When that isn't the case you only have the IP and browser headers to tell you it could be the same user.

The next request can either be a new page request or for example an Ajax request that also sends headers and thus including cookies (if the browser excepts this).

If you attach a unique identifier to the new request uri and get an empty cookie response from him or her, you know the browser does not except cookies.

Xorifelse
  • 7,878
  • 1
  • 27
  • 38