Cookie notes

From Helpful
Jump to: navigation, search
Related to web development, hosting, and such: (See also the webdev category)
jQuery: Introduction, some basics, examples · plugin notes · unsorted

Server stuff:

Dynamic server stuff:


  • Cookie notes
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


Cookies give a website some memory. A server can ask a visiting browser to remember a piece of text, and on a later visit repeat it back verbatim.

Originally that was the only mechanism: A server/site/application asks a browser to store some information. If the browser agrees to do so, it will then send that exact information whenever it returns to that same domain/server/site/application.

Later, scripting added some extra abilities, mostly particular the fact that (browser-side) scripting can ask the browser to change cookie contents - on behalf of the server that served the page. (This is mostly a programmer convenience for some more interactive pages)

One of the easiest things a cookie that lets a server do is recognize that a specific browser returns to visit. It's like giving someone a specific word to repeat back later - you'll know it's them. Many uses of cookies are some variant of this "yup, this is still me" use, but there are others - it depends on what is stored, and how it's used.

Purposes include:

  • keeping users logged in
    • i.e. a token representing "we have recently checked this user's authentication" (and we check that token with via server state).
  • identifying returning users (regardless of login)
    • Can be done anonymously, e.g. storing a number in the cookie (a number that is randomly generated and not meaningful, except in its repeated use in this session)
    • ...which can be used e.g. remember shopping basket state even when you are not logged in yet
    • or remember other state within a session, for a person who hasn't logged into an account, or for a site without accounts
  • extension of the previous point: tracking user visits, usage, or the order in which pages are accessed within a site, for example
doing so requires identifying returning users, cookies happen to be the most convenient way of doing so.
anonymously recording the set of pages that a specific browser visits on a site (or within the domain in which the cookie is set)
otherwise maintaining specific information about users (often relatively anonymously unless you choose to identify yourself to a site/domain that does this, or happen to be identifiable another way)


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Mechanism and syntax

Cookies are from many views just pure text. Their values and related metadata sent in a HTTP header.

A cookie set consists of

  • a set of semicolon-separated predefined parts
  • most of which are optional (will default to certain behaviour when omitted)
  • most of which take the form of attr=value, a few of which take no value

...and actual values to store in the cookie, in the form name=value, which is actually the only required part.

It is fairly common to, beside the name=value, also set an expiry time. Setting a path and domain is also not unusual.

Set-Cookie: foo=newvalue; expires=date; path=relative/path;
Set-Cookie: foo=bar; path=/abs/path; expires Mon, 09-Dec-2002 13:46:00 GMT; secure

Set-Cookie: (RFC2109)

Name and value


Basically just name=value


  • attribute names are case-insensitive
  • the value should be escaped so that it will not clash with parsing -- see RFC 2616's definition of quoted-string
  • if a particular name appears multiple times in a set-cookie, only the first should be used
  • Names starting with $ are reseved and not to be used by applications

You can set a variable name to contain a new value to make the browser overwrite it.

Note that set-cookies with new values only overwrite values for a name when the old and new Domain and Path values are also equal.

Note that an Expires in the past and/or a Max-Age of 0 will cause a cookie to be discarded regardless of value (a common way to delete a cookie).



If omitted, the UA will remove the cookie when it closes - called a session cookie (in the per-session sense).

Cookies with an expiration date will persist between different runs of the browser, until the given expiration. These are sometimes called persistent cookies.



If omitted, the browser defaults it to the host that set it. If you wanted it domain-wide, that's not ideal. In reverse-proxied setups, the browser doing this may be preferable (unless you want a specific wider domain to be set).

The domain/host that sets it must be, or be a member of, the host/domain it wants to set.

This can be handy when you, for example, don't want visits to to be treated as different from visits to, particularly for logins.



If omitted, the browser defaults it to the path that generated the cookie(verify): the requests path up to the rightmost /.

Useful when an application wishes to isolate certain cookie data to just itself, via the pathname that the applicationis hosted under.

If the host represents an application, it may be simpler for your code to force this the path to be '/' so that it applies application-wide and you don't have to worry about where you set it from.


You can optionally require that a cookie should only be set if the connection is secure (HTTPS). this is primarily extra protection against

Set-Cookie2: (RFC2965)

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Set-Cookie2 is an extended form that defines additional attributes, and additional behaviour requirements (see e.g. RFC 2965, section 3.3.1).

It is mentioned that the name must come before attributes, which RFC 2965 it mentions means that you can not cause name collisions. It is probably a good idea to never use a name that matches a pre-defined cookie attribute, though, as not all cookie implementations may be smart about this. This is probably a good idea for Set-Cookie: as well.

Note on support

The idea behind RFC 2965 (from 2000) was that Set-Cookie2 would replace Set-Cookie, but its use caught on slowly, in part because browser support wasn't that fast either.(verify)

Most modern browsers now support both Set-Cookie: and Set-Cookie2:.


Required in the Set-Cookie2 header.

Version=1 refers to implementation according to RFC 2965. There is currently no other version(verify).



Tells the browser to delete the specified cookie, unconditionally (can be handier than doign so via expiration/max-age).


Seconds to keep the cookie.

An easier (and timezone-independent) way to handle expiry.

Zero means that the browser should delete the cookie.



Non-standard extensions


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

From Microsoft.

The idea is that for cookies with this property present, the browser denies scripting from accessing that cookies, so that it cannot be altered or read/stolen via XSS.

It makes sense in that practically, script-interactive use of cookies (such as remembering part of page UI state) can be separated from cookies that have more serious things actually worth stealing (such as login tokens).

HttpOnly was only ever meant as a useful mitigation, never as a solid security solution.

While XSS cannot read/steal the cookie, there are still certain flaws. XSS may in certain cases still effecticely replace/overwrite the cookie's value (but not read it)(verify) (consider attacks such as that creating many new cookies when a browser has a limit per domain - this can flush the oldest, and replace the value with a new cookie).

Most browsers have supported it for a while. For details, see e.g.

Rejection of invalid cookies

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Incompleteness and invalidity will lead browsers to reject cookies.

According to RFC 2965, section 3.3.2, invalid cookie-store requests are those that satisfy one of the following:

  • the path in the cookie is not a prefix of the URI path of the page that set-cookie was requested from (you can't set other paths' cookies)
  • the UA request's effective host not match the cookie's domain (this can be a potential bother when using reverse proxies, named virtual hosts and such. You often want to use request information for the cookie)

There are also a number of logical domain/host requirements

  • often the minimum-total-dot requirement:
    • Two for .com, .net, .org, .edu, .gov, .mil, and .int (verify) (For example, there are two in, so it passes this test)
    • one for .local (verify)
    • Three otherwise (verify)
  • when the domain in the cookie implies that the host part has a dot
    • e.g. a set-cookie from for domain implies that the host is www1.webservers, which contains a dot so is invalid. For this example, you would want to specify the domain
  • the domain does not follow general DNS rules (made of letters, digits, and hyphens [a-z0-9.-]). Note that intranet naming does not always necessarily keep to DNS rules, e.g. by containing underscores. See also Microsoft KB 909264, RFC 952, RFC 1123.

In browsers, incompleteness or invalidity of a cookie may mean the cookie will not be set at all, be used but not persist, and this may differ between browsers and specific types of invalidity.

Note that in (non-transparent) reverse proxying, the path and host for the application may not be the one the browser sees, which can (rightly) lead it to reject the cookie. Having a proxy rewrite cookies is possible, but not always easy to do well.



Storing data directly in a cookie (rather than a token to refer to data elsewhere) is possible, but you cannot count on cookies storing more than approximately 4KB.

Browsers have rules about per-site / total cookie size, in part because having large cookies makes all requests to the host/path, application (or even domain, if you set the domain and path broadly) a little slower, particularly if there are many large cookies.

All this isn't really that large a problem as it is regularly just as convenient to store just an identifier in a cookie, which refers to server-stored state of any simplicity/size you choose.


You shouldn't count on getting more than 20 cookies for any domain, and note that the browser might delete the least-used cookies if it has some amount of total cookies (e.g. the 300 mentioned a few places, 50 in IE7[1]).

Further notes

Deleting a cookie can be done in several ways. You can mention the name with an empty value, and you can mention the name and a new exporation date - one in the past.

Cookie reponses (Cookie: headers) may merge var-val pairs from different origins into one. Cookie libraries will handle such details for you.

When using reverse proxies to apps, note that domain and path should be as the browser sees them, as it makes the decisions about storing and sending cookies based on those.

You can read out cookies for the current page using scripting, and you can set a cookie for the page's originating site. Note this is done purely done at the browser side, and can mean several changes before the browser makes its next HTTP request with a Cookie: header.

This can be useful for things that only ever change interactively, such as interface selection, and is used in google analytics.

Cookies and security


When you log into a website, what it typically does is

check your credentials once, then stores a cookie that "I recently checked your credentials" that it can actively verify
on all later requests (until the cookie, i.e. login, expires), actively verify that cookie

That cookie usually stores a random number, that is completely meaningless in itself, except that both sides remember it for a while.

There are a handful of details to

implementing the thing itself well
some as simple as "make it a large random number to make guessing take thousands of years, so infeasible"
some more complex
not weakening it in other ways, like
accidentally giving someone control of your webpage scripting, as it can also read it off

...but given such care, this is a pretty good system.

It's also the basis of most login systems, largely because without having any way to persist that "I've checked you", you would have to send your credentials every new connection (which for a browser is a at least one and typically a for every refresh)

Minor evil?

There are people who consider cookies a Bad Thing.

There are a few good points.

And a lot of aimless alarmism, and it tends to prevent us from addressing the few good points.

And even the decent points aren't really about cookies, or other technical details about how things are stored, more about what and why and for who, so are less technical and more legal points.

The short story is that cookies can only store data verbatim, either:

  • data that the came directly the server's HTTP response
so can only report to the server what the server previously had anyway
  • data that the scripting started on a page that came from the server's HTTP response (it's considered the same, for sensible reasons)
which can only store what the browser already has anyway
this one's more interesting, but still not bad

Let's address the first of those: server stores what the server had anyway.

The classical example is that a server ask you to report back when you visit it again.

This will be a token that fundamentally has no personal information - it'll be a large random number (making it unlikely to match another one, and very hard to guess), stored in a cookie, and the server's database.
The only thing that server can know is that you are the same browser on the same PC visiting it again.

And the question is how that is used.

One common use is specific returns as login tokens -- the things that keep you logged into a site

note that these don't store or reveal passwords. They are a very-hard-to-guess token, typically a random number, that both sides remember, and within the server logic is a reference to your account
are worth stealing that it lets other people be logged in as you (until that login/cookie expires)
often alleviated, in that more serious actions like 'change account info' or purchases will ask for password again

Another sensible use is a "store in shopping basket before you log in, which will transfer to your account's basket once you log in" feature.

This is convenient, and these cookies are rarely worth stealing - it'd be a bunch of work, and would only get another person's tentative items into your account's basket instead.

A classical example of something more dubious is ad networks.

Consider having a server that serves ads (e.g. images on other sites), on many websites.

Having it store cookies identifies the same browser looks at ads on specific sites and with a little extra trickery lets them figure out one user visits both site X and site Y.

With just that they still cannot know who that person is, but there is some value in profiles that say "people who visit anime site also visit computer sites" in figuring out what ads to show on both those sites, both to anyone, and potentially to just you.

You can argue whether that's a violation of privacy or not.

This was easier for them when third party cookies applied to the embedded ads themselves. Browsers are now a lot stricter with those.

(However, that detail becomes irrelevant when the largest ad network today is probably Facebook, and you are willingly telling them exactly who you are and what you like and that you're okay with them collecting data on you elsewhere and that you specifically clicked OK on legally allowing them to do whatever they want with that.)

See also Security_notes#Cookie-like_things

See also

  • RFC 2109, 'HTTP State Management Mechanism' ((technically) obsoleted by...)
  • RFC 2965, 'HTTP State Management Mechanism'
  • perhaps read RFC 2964, Use of HTTP State Management