log in | register | forums


User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Archive Edition 27:2 reviewed (News:)
- RISC OS 5.30 arrives (News:12)
- Rougol Talk May 2024 - Andy Vawer (News:)
- Rougol May 2024 meeting on monday with Andy Vawer (News:1)
- WROCC May 2024 meeting - Gerph talks games (News:)
- Drag'n'Drop 13i3 edition reviewed (News:1)
- Wakefield Show 2024 in Pictures (News:5)
- April 2024 News Summary (News:2)
- Upgrading your RISC OS system to 5.30 (News:2)
- WROCC May 2024 meeting on wednesday - Gerph talks games (News:)
Related articles
- HTTP: an introduction
- HTTP Status Code Definitions
- CGI Scripting
- WML Resources
- Network Programming on RISC OS
- PackMan in practice, part 2
- PackMan in practice
- Power Switching a RaspberryPi
- Video conversion on RISC OS
- Building the Dream 4 - Random city basics
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
View on Mastodon
Site Search
Article archives
The Icon Bar: News and features: Cookies: an introduction

Cookies: an introduction

Posted by Geoff Potter on 22:36, 4/7/2001 | , ,
Cookies are small pieces of data stored on your computer by a web server. A cookie is set in an http response header by the web server, and returned to the web server in an http request header by the client. Some browsers also allow cookies to be read and set by JavaScript.
They are most commonly used to track, store preferences or shopping cart information from and recognise users.
The majority of the information is based on the Netscape Cookie Specification.

Setting Cookies

For security reasons, web sites cannot create globally accessible cookies that any web site or web page can view. So cookies are set for a particular domain, path, time period and security level.
They are generally set using the Set-Cookie: http response header, when a file is sent, e.g.:
Set-Cookie: MYCOOKIE=VALUE; expires=Thu, 28-Jun-2001 12:13:02 GMT; path=/; domain=iconbar.com
This would mean that any subsequent connection to the iconbar.com would include the following header:
The attributes in the Set-Cookie are as follows:
This specifies the cookie's name and value. These are the only required attributes, all else are optional.
If not set, the cookie will be deleted at the end of the user's session. (i.e. when they quit their web browser)
The date must be the form "Wdy, DD-Mon-YY HH:MM:SS GMT", e.g. Thu, 28-Jun-2001 12:13:02 GMT (This is based on RFC 822, 850, 1036 and 1123, with the exception that only the GMT timezone is permitted and the date separators must be dashes)
If not set, this defaults to the host serving the file, otherwise it is only permitted if the host is within the specified domain. (e.g. fonts.iconbar.com could set a cookie which is valid for iconbar.com and vice versa, but iconbar.com could not set a cookie which is valid for
The specified domain must contain at least two periods if it ends in .com, .edu, .net, .org, .gov, .mil or .int, otherwise it must contain at least three.
If not set, this defaults to the path of the document being served. This limits the cookie to being supplied within the path specified. e.g. If set to '/' it would be sent for all otherwise valid requests to the server, but if set to /foo, it would match /foobar or /foo/bar.html -
i.e. it is simple left hand edge string comparison.
If this is specified then the cookie is only sent over secure (currently only https) connections.


  • Multiple Set-Cookie headers can be included in one response.
  • Cookies must never exceed more than 4Kb in length
  • Max 20 cookies per server/domain
  • Cookies are deleted by setting an expiry time which is in the past
    and specifying the same path and name.

Code Examples


PHP makes the setting and reading of cookies look childishly simple - so I haven't bothered to actually include a sample script at all.
PHP handles the cookies in the same transparent way as it handles the GET and POST variables and can set them as global variables, or just in the $HTTP_COOKIE_VARS array. Despite this, some understanding of how cookies work is required (particularly if you intend to delete unneeded cookies or don't know why a cookie hasn't appeared in the $HTTP_COOKIE_VARS array even though you just set it)
SetCookie($name [,$value [,$expires [,$path [,$domain [,$secure]]]]]); will only work before headers have been sent (check using if (!headers_sent()) setcookie(...);)
The major differences to note are that

  • expires is a unix timestamp (i.e. seconds from 1/1/1970)
  • secure is an boolean value (ie. not the string 'secure')
All other values passed should be the required string values for the setting cookies using the Set-Cookie: response header, with the exception that encoding is not required (PHP will automatically urlencode and decode the names and values).

In Perl

Unless using CGI.pm or cgi-lib.pl, you'll have to do all the handling of cookies using environment variables and headers.
Download perl (en|de)coder
Setting cookies will need to be done before anything is sent to the client (other than other headers :), suitably encoding the data and using the Set-Cookie: header.


Cookies will need to be dealt with as in Perl.

Related Links

Log in to comment on this article

The Icon Bar: News and features: Cookies: an introduction