What is/are the actual practical difference/s in functioning of the built-in functions setcookie() and setrawcookie() in PHP?

Question

I'm learning one of the most important concept of Cookies in PHP in detail.

While studying Cookies I come to know that "The value of the cookie is automatically URLencoded when sending the cookie, and automatically decoded when received (to prevent URLencoding, use setrawcookie() instead)."

The above statement has created so many doubts in my mind which are as follows :

1. What does actually happen practically by means of "The value of the cookie is automatically URLencoded when sending the cookie, and automatically decoded when received" ?
2. Why there is a need of another function like setrawcookie() when there is already a function setcookie() available for setting the cookie values?
3. Is the process of URL encoding and URL decoding unsafe/harmful/ hazardous/slow/anything else so that it should be avoided?
4. What are the benefits/drawbacks of using setrawcookie() over setcookie()?
5. Which one is safe/better/secure/reliable/etc. setcookie() or setrawcookie()?
6. Can't the cookies be set like other variables like $_COOKIE['cookie_variable'] = 'some_value' instead of using setcookie() or setrawcookie()?

If someone could clear all of my above mentioned doubts with perfect, suitable and easy to understand code examples along with the step-by-step crispy, lucid, easy to grasp explanation it would be of great great help to me.

Thanks.

Answer 1

1. What does actually happen practically by means of "The value of the cookie is automatically URLencoded when sending the cookie, and automatically decoded when received" ?

It means that you don't have to worry about special characters.

Note that cookies are not a PHP concept; they're an extension to the HTTP protocol. And every protocol has a rigid structure that you need to comply with, or it simply wouldn't work. That structure relies on delimiters - characters, or sequences of characters that have special meaning assigned to them within that protocol.
It is inevitable that data transferred through every protocol will contain those special chracters, and that's why encoding is necessary.

For example, the semicolon (;) is used as a separator in the Set-Cookie HTTP Header, so if your cookie value contains it, it needs to be encoded or otherwise the cookie wouldn't be properly parsed by browsers when they receive it.

If you send a cookie with a value of foo;bar, without encoding, browsers will treat it as the value foo with a bar flag attached to it.
You would lose ;bar as part of the data, and since bar is an unknown flag according to the protocol, browsers will simply ignore it, so you wouldn't even know that there was an error at all.

PHP will automatically do the encoding when you set a cookie with setcookie(), and then automatically decode it when you read from the $_COOKIE super-global.

2. Why there is a need of another function like setrawcookie() when there is already a function setcookie() available for setting the cookie values?

Mainly for 2 reasons:

1. The value you are sending may already be encoded.

   You want to avoid double encoding, because at best it means you need to do more work. In the worst case, it may completely corrupt the data (i.e. you may never be 100% sure what the original data was).

2. There are many ways to encode values, and the one setcookie() uses may not be desirable.

   URL-encoding often encodes more data than the cookie format needs it to.
   In extreme cases (you should never have to be concerned with this), since encoded data is usually larger in size the original, it may cause it to exceed the maximum cookie size (about 4kb). Or you may simply want to save bandwidth.

But is also not uncommon that you know 100% that the data doesn't need encoding, so you simply want to skip that unnecessary step.

3. Is the process of URL encoding and URL decoding unsafe/harmful/ hazardous/slow/anything else so that it should be avoided?

Not in general, but this should already be answered above.

4. What are the benefits/drawbacks of using setrawcookie() over setcookie()?

The drawback is that you need to encode the values yourself, if necessary.
The benefits are, again, already explained above.

5. Which one is safe/better/secure/reliable/etc. setcookie() or setrawcookie()?

setcookie() leaves less room for errors from people unfamiliar with the cookie protocol.

But that comes at a cost - the assumption that you always want URL-encoding. And assumptions are generally a bad thing in programming.

For a newbie, setcookie() is easier to use.
For an expert, setrawcookie() puts less restrictions and is thus more flexible.

Neither is inherently better, and since you mentioned "secure" - neither has any effect on security.

6. Can't the cookies be set like other variables like $_COOKIE['cookie_variable'] = 'some_value' instead of using setcookie() or setrawcookie()?

No.

Answer 2

URL encoding replaces specific characters which have a special meaning in URLs/HTTP with percent-encoded characters, e.g. a space becomes %20. See https://en.wikipedia.org/wiki/Percent-encoding for the gory details.

You need setrawcookie if you want to set a cookie that you have already URL-encoded yourself, for whatever reason. So if you have an already encoded cookie with the value %20 in it, if you use setcookie it will be encoded to %2520; using setrawcookie it will be preserved as is and be set as %20. In other words, setrawcookie is a way to "just set the damn cookie, I know what I'm doing." Using it it's up to you to ensure the cookie format is correctly conforming to HTTP character encoding standards.

See The Great Escapism (Or: What You Need To Know To Work With Text Within Text) if you need more background information on what encodings or escape formats are in the first place.