Cookies

A cookie is a piece of data that is received from a server in response to a request. Cookies may be sent back again to a server within a request if certain conditions are met. The data portion of a cookie can be used by a server to keep state between different requests, which may be necessary because of the stateless nature of HTTP. A cookie is either a session cookie with a lifetime limited to the current session, or it is a persistent cookie, in which case it is usually saved in a file in order to be remembered later.

Specification

The format of a cookie received in a response from a server looks like:

Set-Cookie: NAME=VALUE; domain=DOMAIN; path=PATH; expires=DATE

The parameters domain=, path= and expires= are all optional with certain default values: A missing DOMAIN is replaced by the hostname as used in the request while a missing PATH is set to the /directory/ part of the requesting URL. An absent DATE turns the cookie into a session cookie while a DATE in the past deletes a valid cookie.

The first part of a cookie definition is mandatory and defines an opaque VALUE with NAME, overwriting an already present value with the same NAME, but only when also matching DOMAIN and PATH. The definition of a cookie is bound to DOMAIN and PATH, and is valid and accepted only if DOMAIN is a suffix of the hostname and PATH is a prefix of the path, both as used in the request, otherwise the cookie definition is just ignored.

The format of cookies sent back to a server in a request looks like:

Cookie: NAME1=VALUE1; NAME2=VALUE2; ...

The NAME-VALUE pairs are derived from all currently defined cookies whose DOMAIN is a suffix of the hostname and whose PATH is a prefix of the path of the request. The pairs are sorted so that a NAME originating from a longer path prefix comes first.

More about the specification of cookies can be found in [COOKIE].

Implementation

The treatment of cookies within w3browse is very restrictive in order to ensure privacy as much as possible. All cookies are handled like session cookies, that is, they are never stored permanently anywhere. Furthermore, cookies are usually not shared between different request contexts and a valid cookie from a server is sent back only to that server again regardless of the specified DOMAIN, which is just used to check if a cookie is valid.

The NAME-VALUE pairs of cookies are associated to prefixes of requesting URLs. Such a prefix is the combination of the scheme and netloc parts together with the specified PATH, which is also checked for validity against the URL of the request when a cookie is defined. A given DATE value is just used to check whether to delete a valid cookie or not. In deciding which cookies to send back to a server in a request, only cookies whose associated prefix is a prefix of the requesting URL are taken into account.