Things have certainly gotten better during these years. Early WAP devices did not support Cookies. In theory the combination of the WAP gateway and the WAP browser should have supported Cookies from the beginning. This meant that if the browser did not support Cookies, the WAP Gateway was supposed to do it.
In facts this has been true only partly. Sometimes Cookie support in WAP 1 devices was limited by the size, for example. In some other cases, content providers and software developers did not really trust gateways and were concerned about their users privacy. Another topic that has never been really cleared was what would happen if the Cookie was set to expire in 1 week, for example and it was stored on the WAP Gateway. What would happen when the mobile device was turned off (or simply quit browsing) and maybe visit the same site in two days?
The result has been that most sites have completely avoided Cookies and used what is commonly called URL decoration instead. URL decoration means adding a sessionid to the Query_string.
In short, unless you are really sure the current browser supports Cookies or you know that the current WAP gateway will support Cookies in place of the mobile browser, our suggestion is to avoid using Cookies, or at least do not rely entirely on them. Store some extra information that you might live without easily.
Things have gotten much better since WAP 1, first of all because the OMA has worked on the topic and also because mobile device’s hardware has improved a lot during these years. Better CPU’s and more memory certainly help in these fields.
Obviously, mobile browsers have gotten better too.
According to the OMA HTTP State Management spec now at least 4 cookies of at least 125 bytes each, for a total of 500 bytes storage are required.
Specifically, the Openwave browser V6, for example, supports cookies natively, i.e. it doesn’t require a gateway. Default cookie jar size is 4K, considerably larger than the required minimum from OMA.
WAP browsers have security settings. Users might disable cookies or might configure the browser to delete them at the end of the session. This could remove your cookies.
While WAP gateways are supposed to be able to also manage cookies for WAP browsers that are not able, some might be configured to STRIP them.
For these reasons you should take all the reasonable steps to provide your site with the needed tools to work this around. Cookies are a great thing and since WAP 2 they are mostly supported. Nevertheless you should consider occasions in which they will not work.
To test Cookie-support you can use the script located at demos page. WML support is required on your browser.
The first time you view the card, the counter should read 0 (zero). All caching has been turned off, and to support even the poorest of the WML browsers, the card forces a reload of itself by adding a random variable to the URL. (I do not recommend this method of forcing a reload). When you click on the Increase Counter link, the deck will reload, and the card should reappear with the counter increased to 1 (one) and so on.
The Cookie name in the script is called TestCookie, and it has a very long life span, so if you return to the script several days later, the counter should read the number you last saw - i.e. not 0 (zero). This only applies if you return with the same type of environment that you last visited the script with. If you somehow clear your locally stored cookie data, the counter will again start at 0 (zero).
If the counter reads 0 (zero) over and over again, a cookie is not passed to the web server. The script also attempts to check if a cookie was passed and will tell you this.
In addition, the script also displays the HTTP header string HTTP_VIA and HTTP_USER_AGENT which should give you some indication as to which gateway make and model you are using. Some gateways identifies themselves via HTTP_VIA and some via HTTP_USER_AGENT and some gateways are made by programmers that just couldn’t be bothered.
The code for the test script is available below. This is PHP code, but a standard PHP setcookie() function equivalent will exist in most popular script languages, and that’s pretty much the only special thing with the script. The function simply sets the cookie, and the PHP variable $HTTP_COOKIE_VARS is used to read the cookie.
<?php if(isset($HTTP_COOKIE_VARS["TestCookie"])) { // Check if TestCookie is set $cookieset = "set"; $cookieid = $HTTP_COOKIE_VARS["TestCookie"]; // Read the Cookie $cookieid++; // and increase its value } else { $cookieset = "not set"; // cookie was not set $cookieid = 0; // start counter at zero } setcookie("TestCookie",$cookieid); // apply the Cookie to the HTTP header header("Content-type: text/vnd.wap.wml"); // set the content type for WML header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // disable ALL caching header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: no-cache, must-revalidate"); header("Pragma: no-cache"); echo("<?xml version=\"1.0\"?>\n"); echo("<!DOCTYPE wml PUBLIC \"-//WAPFORUM//DTD WML 1.1//EN\" \"http://www.wapforum.org/DTD/wml_1.1.xml\">\n\n"); echo("<!-- This application attempts to test the capabilities of a WAP gateway to support cookies -->\n"); echo("<!-- App by Espen.Lyngaas@colorline.no (c) 2000 -->\n"); $random = mt_rand(100000,999999); // Generate random value for reload forcing ?> <wml> <head> <meta forua="true" http-equiv="Cache-Control" content="must-revalidate"/> // Even more cache disabling </head> <card id="init" title="CookieTest"> <p>Cookie "TestCookie" was <?echo($cookieset)?>. Value is currently "<?echo($cookieid)?>"</p> <p><anchor>Increase value<go method="get" href="<?echo($PHP_SELF)?>?random=<?echo($random)?>"/></anchor></p> <p>Gateway: <? if(isset($HTTP_VIA)) { // Is there something in the HTTP_VIA variable? echo($HTTP_VIA); } else { if(isset($HTTP_USER_AGENT)) { // Is there something in the HTTP_USER_AGENT variable? echo($HTTP_USER_AGENT); } else { echo("Unknown"); // Absolutely no identifier was found } } ?> </p> </card> </wml>