The http.cookiejar module defines classes for automatic handling of HTTP
cookies. It is useful for accessing web sites that require small pieces of data
– cookies – to be set on the client machine by an HTTP response from a
web server, and then returned to the server in later HTTP requests.

Both the regular Netscape cookie protocol and the protocol defined by
RFC 2965 are handled. RFC 2965 handling is switched off by default.
RFC 2109 cookies are parsed as Netscape cookies and subsequently treated
either as Netscape or RFC 2965 cookies according to the ‘policy’ in effect.
Note that the great majority of cookies on the Internet are Netscape cookies.
http.cookiejar attempts to follow the de-facto Netscape cookie protocol (which
differs substantially from that set out in the original Netscape specification),
including taking note of the max-age and port cookie-attributes
introduced with RFC 2965.

Note

The various named parameters found in Set-Cookie and
Set-Cookie2 headers (eg. domain and expires) are
conventionally referred to as attributes. To distinguish them from
Python attributes, the documentation for this module uses the term
cookie-attribute instead.

The CookieJar class stores HTTP cookies. It extracts cookies from HTTP
requests, and returns them in HTTP responses. CookieJar instances
automatically expire contained cookies when necessary. Subclasses are also
responsible for storing and retrieving cookies from a file or database.

Constructor arguments should be passed as keyword arguments only.
blocked_domains is a sequence of domain names that we never accept cookies
from, nor return cookies to. allowed_domains if not None, this is a
sequence of the only domains for which we accept and return cookies. For all
other arguments, see the documentation for CookiePolicy and
DefaultCookiePolicy objects.

DefaultCookiePolicy implements the standard accept / reject rules for
Netscape and RFC 2965 cookies. By default, RFC 2109 cookies (ie. cookies
received in a Set-Cookie header with a version cookie-attribute of
1) are treated according to the RFC 2965 rules. However, if RFC 2965 handling
is turned off or rfc2109_as_netscape is True, RFC 2109 cookies are
‘downgraded’ by the CookieJar instance to Netscape cookies, by
setting the version attribute of the Cookie instance to 0.
DefaultCookiePolicy also provides some parameters to allow some
fine-tuning of policy.

This class represents Netscape, RFC 2109 and RFC 2965 cookies. It is not
expected that users of http.cookiejar construct their own Cookie
instances. Instead, if necessary, call make_cookies() on a
CookieJar instance.

The specification of the original Netscape cookie protocol. Though this is
still the dominant protocol, the ‘Netscape cookie protocol’ implemented by all
the major browsers (and http.cookiejar) only bears a passing resemblance to
the one sketched out in cookie_spec.html.

If policy allows (ie. the rfc2965 and hide_cookie2 attributes of
the CookieJar‘s CookiePolicy instance are true and false
respectively), the Cookie2 header is also added when appropriate.

The request object (usually a urllib.request..Request instance)
must support the methods get_full_url(), get_host(),
get_type(), unverifiable(), get_origin_req_host(),
has_header(), get_header(), header_items(), and
add_unredirected_header(), as documented by urllib.request.

The request object (usually a urllib.request.Request instance)
must support the methods get_full_url(), get_host(),
unverifiable(), and get_origin_req_host(), as documented by
urllib.request. The request is used to set default values for
cookie-attributes as well as for checking that the cookie is allowed to be
set.

If invoked without arguments, clear all cookies. If given a single argument,
only cookies belonging to that domain will be removed. If given two arguments,
cookies belonging to the specified domain and URL path are removed. If
given three arguments, then the cookie with the specified domain, path and
name is removed.

Discards all contained cookies that have a true discard attribute
(usually because they had either no max-age or expires cookie-attribute,
or an explicit discard cookie-attribute). For interactive browsers, the end
of a session usually corresponds to closing the browser window.

filename is the name of file in which to save cookies. If filename is not
specified, self.filename is used (whose default is the value passed to
the constructor, if any); if self.filename is None,
ValueError is raised.

ignore_discard: save even cookies set to be discarded. ignore_expires: save
even cookies that have expired

The file is overwritten if it already exists, thus wiping all the cookies it
contains. Saved cookies can be restored later using the load() or
revert() methods.

If true, load cookies lazily from disk. This attribute should not be assigned
to. This is only a hint, since this only affects performance, not behaviour
(unless the cookies on disk are changing). A CookieJar object may
ignore it. None of the FileCookieJar classes included in the standard
library lazily loads cookies.

A FileCookieJar that can load from and save cookies to disk in the
Mozilla cookies.txt file format (which is also used by the Lynx and Netscape
browsers).

Note

This loses information about RFC 2965 cookies, and also about newer or
non-standard cookie-attributes such as port.

Warning

Back up your cookies before saving if you have cookies whose loss / corruption
would be inconvenient (there are some subtleties which may lead to slight
changes in the file over a load / save round-trip).

Also note that cookies saved while Mozilla is running will get clobbered by
Mozilla.

A FileCookieJar that can load from and save cookies to disk in format
compatible with the libwww-perl library’s Set-Cookie3 file format. This is
convenient if you want to store cookies in a human-readable file.

This method is an optimization. It removes the need for checking every cookie
with a particular domain (which might involve reading many files). Returning
true from domain_return_ok() and path_return_ok() leaves all the
work to return_ok().

Note that domain_return_ok() is called for every cookie domain, not just
for the request domain. For example, the function might be called with both
".example.com" and "www.example.com" if the request domain is
"www.example.com". The same goes for path_return_ok().

In addition to implementing the methods above, implementations of the
CookiePolicy interface must also supply the following attributes,
indicating which protocols should be used, and how. All of these attributes may
be assigned to.

Don’t add Cookie2 header to requests (the presence of this header
indicates to the server that we understand RFC 2965 cookies).

The most useful way to define a CookiePolicy class is by subclassing
from DefaultCookiePolicy and overriding some or all of the methods
above. CookiePolicy itself may be used as a ‘null policy’ to allow
setting and receiving any and all cookies (this is unlikely to be useful).

In addition to the features required to implement the CookiePolicy
interface, this class allows you to block and allow domains from setting and
receiving cookies. There are also some strictness switches that allow you to
tighten up the rather loose Netscape protocol rules a little bit (at the cost of
blocking some benign cookies).

A domain blacklist and whitelist is provided (both off by default). Only domains
not in the blacklist and present in the whitelist (if the whitelist is active)
participate in cookie setting and returning. Use the blocked_domains
constructor argument, and blocked_domains() and
set_blocked_domains() methods (and the corresponding argument and methods
for allowed_domains). If you set a whitelist, you can turn it off again by
setting it to None.

Domains in block or allow lists that do not start with a dot must equal the
cookie domain to be matched. For example, "example.com" matches a blacklist
entry of "example.com", but "www.example.com" does not. Domains that do
start with a dot are matched by more specific domains too. For example, both
"www.example.com" and "www.coyote.example.com" match ".example.com"
(but "example.com" itself does not). IP addresses are an exception, and
must match exactly. For example, if blocked_domains contains "192.168.1.2"
and ".168.1.2", 192.168.1.2 is blocked, but 193.168.1.2 is not.

If true, request that the CookieJar instance downgrade RFC 2109 cookies
(ie. cookies received in a Set-Cookie header with a version
cookie-attribute of 1) to Netscape cookies by setting the version attribute of
the Cookie instance to 0. The default value is None, in which
case RFC 2109 cookies are downgraded if and only if RFC 2965 handling is turned
off. Therefore, RFC 2109 cookies are downgraded by default.

Follow RFC 2965 rules on unverifiable transactions (usually, an unverifiable
transaction is one resulting from a redirect or a request for an image hosted on
another site). If this is false, cookies are never blocked on the basis of
verifiability

Cookies that did not explicitly specify a domain cookie-attribute can only
be returned to a domain equal to the domain that set the cookie (eg.
spam.example.com won’t be returned cookies from example.com that had no
domain cookie-attribute).

Cookie instances have Python attributes roughly corresponding to the
standard cookie-attributes specified in the various cookie standards. The
correspondence is not one-to-one, because there are complicated rules for
assigning default values, because the max-age and expires
cookie-attributes contain equivalent information, and because RFC 2109 cookies
may be ‘downgraded’ by http.cookiejar from version 1 to version 0 (Netscape)
cookies.

Assignment to these attributes should not be necessary other than in rare
circumstances in a CookiePolicy method. The class does not enforce
internal consistency, so you should know what you’re doing if you do that.

Integer or None. Netscape cookies have version 0. RFC 2965 and
RFC 2109 cookies have a version cookie-attribute of 1. However, note that
http.cookiejar may ‘downgrade’ RFC 2109 cookies to Netscape cookies, in which
case version is 0.

True if this cookie was received as an RFC 2109 cookie (ie. the cookie
arrived in a Set-Cookie header, and the value of the Version
cookie-attribute in that header was 1). This attribute is provided because
http.cookiejar may ‘downgrade’ RFC 2109 cookies to Netscape cookies, in
which case version is 0.

The next example illustrates the use of DefaultCookiePolicy. Turn on
RFC 2965 cookies, be more strict about domains when setting and returning
Netscape cookies, and block some domains from setting cookies or having them
returned: