http.cookiejar — Cookie-Handling für HTTP-Clients

Quellcode: Lib/http/cookiejar.py

Das Modul http.cookiejar definiert Klassen für die automatische Behandlung von HTTP-Cookies. Es ist nützlich für den Zugriff auf Webseiten, die kleine Datenstücke – Cookies – benötigen, die vom Webserver in einer HTTP-Antwort auf dem Client-Rechner gesetzt und dann in späteren HTTP-Anfragen an den Server zurückgegeben werden.

Sowohl das reguläre Netscape-Cookie-Protokoll als auch das von RFC 2965 definierte Protokoll werden behandelt. RFC 2965-Handling ist standardmäßig ausgeschaltet. RFC 2109-Cookies werden als Netscape-Cookies geparst und anschließend je nach geltender „Richtlinie“ entweder als Netscape- oder RFC 2965-Cookies behandelt. Beachten Sie, dass die überwiegende Mehrheit der Cookies im Internet Netscape-Cookies sind. http.cookiejar versucht, dem De-facto-Netscape-Cookie-Protokoll zu folgen (das sich erheblich von dem in der ursprünglichen Netscape-Spezifikation dargelegten unterscheidet), einschließlich der Berücksichtigung der mit RFC 2965 eingeführten Cookie-Attribute max-age und port.

Hinweis

Die verschiedenen benannten Parameter, die in den Headern Set-Cookie und Set-Cookie2 gefunden werden (z. B. domain und expires), werden konventionell als Attribute bezeichnet. Um sie von Python-Attributen zu unterscheiden, verwendet die Dokumentation dieses Moduls stattdessen den Begriff Cookie-Attribut.

Das Modul definiert die folgende Ausnahme

exception http.cookiejar.LoadError

Instanzen von FileCookieJar lösen diese Ausnahme bei fehlgeschlagenem Laden von Cookies aus einer Datei aus. LoadError ist eine Unterklasse von OSError.

Geändert in Version 3.3: LoadError war früher ein Untertyp von IOError, das jetzt ein Alias von OSError ist.

Die folgenden Klassen werden bereitgestellt

class http.cookiejar.CookieJar(policy=None)

policy ist ein Objekt, das die Schnittstelle CookiePolicy implementiert.

Die Klasse CookieJar speichert HTTP-Cookies. Sie extrahiert Cookies aus HTTP-Anfragen und gibt sie in HTTP-Antworten zurück. CookieJar-Instanzen lassen enthaltene Cookies bei Bedarf automatisch ablaufen. Unterklassen sind auch für die Speicherung und den Abruf von Cookies aus Dateien oder Datenbanken verantwortlich.

class http.cookiejar.FileCookieJar(filename=None, delayload=None, policy=None)

policy ist ein Objekt, das die Schnittstelle CookiePolicy implementiert. Für die anderen Argumente siehe die Dokumentation der entsprechenden Attribute.

Ein CookieJar, der Cookies von einer Datei auf der Festplatte laden und möglicherweise dort speichern kann. Cookies werden **nicht** aus der angegebenen Datei geladen, bis entweder die Methode load() oder revert() aufgerufen wird. Unterklassen dieser Klasse sind im Abschnitt FileCookieJar-Unterklassen und Zusammenarbeit mit Webbrowsern dokumentiert.

Dies sollte nicht direkt initialisiert werden – verwenden Sie stattdessen die nachstehenden Unterklassen.

Geändert in Version 3.8: Der Parameter `filename` unterstützt ein pfadähnliches Objekt.

class http.cookiejar.CookiePolicy

Diese Klasse ist dafür verantwortlich zu entscheiden, ob jeder Cookie vom Server akzeptiert oder an diesen zurückgegeben werden soll.

class http.cookiejar.DefaultCookiePolicy(blocked_domains=None, allowed_domains=None, netscape=True, rfc2965=False, rfc2109_as_netscape=None, hide_cookie2=False, strict_domain=False, strict_rfc2965_unverifiable=True, strict_ns_unverifiable=False, strict_ns_domain=DefaultCookiePolicy.DomainLiberal, strict_ns_set_initial_dollar=False, strict_ns_set_path=False, secure_protocols=('https', 'wss'))

Konstruktorargumente müssen als Schlüsselwortargumente übergeben werden. blocked_domains ist eine Sequenz von Domainnamen, von denen wir niemals Cookies akzeptieren oder an die wir Cookies zurückgeben. allowed_domains, wenn nicht None, ist eine Sequenz der einzigen Domains, für die wir Cookies akzeptieren und zurückgeben. secure_protocols ist eine Sequenz von Protokollen, für die sichere Cookies hinzugefügt werden können. Standardmäßig werden https und wss (sicheres WebSocket) als sichere Protokolle betrachtet. Für alle anderen Argumente siehe die Dokumentation für CookiePolicy und DefaultCookiePolicy-Objekte.

DefaultCookiePolicy implementiert die standardmäßigen Akzeptanz-/Ablehnungsregeln für Netscape- und RFC 2965-Cookies. Standardmäßig werden RFC 2109-Cookies (d. h. Cookies, die in einem Set-Cookie-Header mit einem Cookie-Attribut `version=1` empfangen werden) gemäß den RFC 2965-Regeln behandelt. Wenn jedoch das RFC 2965-Handling ausgeschaltet ist oder rfc2109_as_netscape True ist, werden RFC 2109-Cookies von der CookieJar-Instanz zu Netscape-Cookies „heruntergestuft“, indem das Attribut version der Cookie-Instanz auf 0 gesetzt wird. DefaultCookiePolicy bietet auch einige Parameter zur Feinabstimmung der Richtlinie.

class http.cookiejar.Cookie

Diese Klasse repräsentiert Netscape-, RFC 2109- und RFC 2965-Cookies. Es wird nicht erwartet, dass Benutzer von http.cookiejar ihre eigenen Cookie-Instanzen erstellen. Rufen Sie stattdessen bei Bedarf make_cookies() auf einer CookieJar-Instanz auf.

Siehe auch

Modul urllib.request

URL-Öffnung mit automatischer Cookie-Behandlung.

Modul http.cookies

HTTP-Cookie-Klassen, die hauptsächlich für serverseitigen Code nützlich sind. Die Module http.cookiejar und http.cookies hängen nicht voneinander ab.

https://curl.se/rfc/cookie_spec.html

Die Spezifikation des ursprünglichen Netscape-Cookie-Protokolls. Obwohl dies immer noch das dominierende Protokoll ist, hat das von allen großen Browsern (und http.cookiejar implementierte „Netscape-Cookie-Protokoll“ nur eine oberflächliche Ähnlichkeit mit dem in cookie_spec.html skizzierten.

RFC 2109 - HTTP State Management Mechanism

Veraltet durch RFC 2965. Verwendet Set-Cookie mit version=1.

RFC 2965 - HTTP State Management Mechanism

Das Netscape-Protokoll mit den behobenen Fehlern. Verwendet Set-Cookie2 anstelle von Set-Cookie. Nicht weit verbreitet.

https://kristol.org/cookie/errata.html

Unfertige Errata zu RFC 2965.

RFC 2964 - Verwendung von HTTP State Management

CookieJar- und FileCookieJar-Objekte

CookieJar-Objekte unterstützen das Iterator-Protokoll zur Iteration über enthaltene Cookie-Objekte.

CookieJar hat die folgenden Methoden

Fügt der request den korrekten Cookie-Header hinzu.

Wenn die Richtlinie dies zulässt (d. h. die Attribute rfc2965 und hide_cookie2 der CookieJar-Instanz wahr bzw. falsch sind), wird bei Bedarf auch der Cookie2-Header hinzugefügt.

Das request-Objekt (normalerweise eine Instanz von urllib.request.Request) muss die Methoden get_full_url(), has_header(), get_header(), header_items(), add_unredirected_header() und die Attribute host, type, unverifiable und origin_req_host unterstützen, wie von urllib.request dokumentiert.

Geändert in Version 3.3: Das request-Objekt benötigt das Attribut origin_req_host. Die Abhängigkeit von der veralteten Methode get_origin_req_host() wurde entfernt.

CookieJar.extract_cookies(response, request)

Extrahiert Cookies aus der HTTP-response und speichert sie im CookieJar, sofern dies von der Richtlinie erlaubt ist.

Der CookieJar sucht nach zulässigen Set-Cookie und Set-Cookie2-Headern im response-Argument und speichert Cookies entsprechend (vorbehaltlich der Zustimmung der Methode CookiePolicy.set_ok()).

Das response-Objekt (normalerweise das Ergebnis eines Aufrufs von urllib.request.urlopen() oder ähnlich) sollte eine Methode info() unterstützen, die eine Instanz von email.message.Message zurückgibt.

Das request-Objekt (normalerweise eine Instanz von urllib.request.Request) muss die Methode get_full_url() und die Attribute host, unverifiable und origin_req_host unterstützen, wie von urllib.request dokumentiert. Die Anfrage wird verwendet, um Standardwerte für Cookie-Attribute festzulegen sowie um zu überprüfen, ob das Cookie gesetzt werden darf.

Geändert in Version 3.3: Das request-Objekt benötigt das Attribut origin_req_host. Die Abhängigkeit von der veralteten Methode get_origin_req_host() wurde entfernt.

CookieJar.set_policy(policy)

Setzt die zu verwendende CookiePolicy-Instanz.

CookieJar.make_cookies(response, request)

Gibt eine Sequenz von Cookie-Objekten zurück, die aus dem response-Objekt extrahiert wurden.

Siehe die Dokumentation für extract_cookies() für die erforderlichen Schnittstellen der Argumente response und request.

Setzt ein Cookie, wenn die Richtlinie dies zulässt.

Setzt ein Cookie, ohne die Richtlinie zu prüfen, ob es gesetzt werden soll oder nicht.

CookieJar.clear([domain[, path[, name]]])

Löscht einige Cookies.

Wenn ohne Argumente aufgerufen, werden alle Cookies gelöscht. Wenn ein einzelnes Argument angegeben wird, werden nur Cookies entfernt, die zu dieser domain gehören. Wenn zwei Argumente angegeben werden, werden Cookies entfernt, die zur angegebenen domain und zum URL-path gehören. Wenn drei Argumente angegeben werden, wird das Cookie mit der angegebenen domain, dem path und dem name entfernt.

Löst KeyError aus, wenn kein passendes Cookie vorhanden ist.

CookieJar.clear_session_cookies()

Verwirft alle Session-Cookies.

Verwirft alle enthaltenen Cookies, die ein wahres discard-Attribut haben (normalerweise, weil sie entweder kein Cookie-Attribut max-age oder expires oder ein explizites Cookie-Attribut discard hatten). Für interaktive Browser entspricht das Ende einer Sitzung normalerweise dem Schließen des Browserfensters.

Beachten Sie, dass die Methode save() Session-Cookies sowieso nicht speichert, es sei denn, Sie fordern dies durch Übergabe eines wahren ignore_discard-Arguments an.

FileCookieJar implementiert die folgenden zusätzlichen Methoden

FileCookieJar.save(filename=None, ignore_discard=False, ignore_expires=False)

Speichert Cookies in einer Datei.

Diese Basisklasse löst NotImplementedError aus. Unterklassen können diese Methode unausgeführt lassen.

filename ist der Name der Datei, in der Cookies gespeichert werden sollen. Wenn filename nicht angegeben ist, wird self.filename verwendet (dessen Standardwert der an den Konstruktor übergebene Wert ist, falls vorhanden); wenn self.filename None ist, wird ValueError ausgelöst.

ignore_discard: speichert auch Cookies, die zum Verwerfen markiert sind. ignore_expires: speichert auch abgelaufene Cookies

Die Datei wird überschrieben, wenn sie bereits existiert, wodurch alle darin enthaltenen Cookies gelöscht werden. Gespeicherte Cookies können später mit den Methoden load() oder revert() wiederhergestellt werden.

FileCookieJar.load(filename=None, ignore_discard=False, ignore_expires=False)

Lädt Cookies aus einer Datei.

Alte Cookies werden beibehalten, es sei denn, sie werden durch neu geladene überschrieben.

Die Argumente sind dieselben wie für save().

Die angegebene Datei muss im von der Klasse verstandenen Format vorliegen, andernfalls wird LoadError ausgelöst. Außerdem kann OSError ausgelöst werden, z. B. wenn die Datei nicht existiert.

Geändert in Version 3.3: IOError wurde früher ausgelöst, es ist jetzt ein Alias von OSError.

FileCookieJar.revert(filename=None, ignore_discard=False, ignore_expires=False)

Alle Cookies löschen und Cookies aus einer gespeicherten Datei neu laden.

revert() kann die gleichen Ausnahmen auslösen wie load(). Bei einem Fehler wird der Zustand des Objekts nicht verändert.

FileCookieJar Instanzen haben die folgenden öffentlichen Attribute

FileCookieJar.filename

Dateiname der Standarddatei, in der Cookies gespeichert werden. Dieses Attribut kann zugewiesen werden.

FileCookieJar.delayload

Wenn true, Cookies verzögert von der Festplatte laden. Dieses Attribut sollte nicht zugewiesen werden. Dies ist nur ein Hinweis, da dies nur die Leistung beeinflusst, nicht das Verhalten (es sei denn, die Cookies auf der Festplatte ändern sich). Ein CookieJar Objekt kann ihn ignorieren. Keine der in der Standardbibliothek enthaltenen FileCookieJar Klassen lädt Cookies verzögert.

FileCookieJar-Unterklassen und Zusammenarbeit mit Webbrowsern

Die folgenden CookieJar-Unterklassen werden zum Lesen und Schreiben bereitgestellt.

class http.cookiejar.MozillaCookieJar(filename=None, delayload=None, policy=None)

Ein FileCookieJar, das Cookies im Mozilla cookies.txt-Dateiformat (das auch von curl und den Browsern Lynx und Netscape verwendet wird) von der Festplatte laden und in diese speichern kann.

Hinweis

Dies führt zu Informationsverlusten bezüglich RFC 2965 Cookies und auch bezüglich neuerer oder nicht standardmäßiger Cookie-Attribute wie port.

Warnung

Erstellen Sie Sicherungskopien Ihrer Cookies, bevor Sie sie speichern, wenn Sie Cookies haben, deren Verlust/Beschädigung unpraktisch wäre (es gibt einige Feinheiten, die zu geringfügigen Änderungen in der Datei über einen Lade-/Speicher-Roundtrip führen können).

Beachten Sie auch, dass Cookies, die während der Ausführung von Mozilla gespeichert werden, von Mozilla überschrieben werden.

class http.cookiejar.LWPCookieJar(filename=None, delayload=None, policy=None)

Ein FileCookieJar, das Cookies von der Festplatte im Format laden und in dieses speichern kann, das mit dem Set-Cookie3-Dateiformat der libwww-perl-Bibliothek kompatibel ist. Dies ist praktisch, wenn Sie Cookies in einer für Menschen lesbaren Datei speichern möchten.

Geändert in Version 3.8: Der Parameter `filename` unterstützt ein pfadähnliches Objekt.

CookiePolicy-Objekte

Objekte, die die CookiePolicy-Schnittstelle implementieren, haben die folgenden Methoden

CookiePolicy.set_ok(cookie, request)

Gibt einen booleschen Wert zurück, der angibt, ob ein Cookie vom Server akzeptiert werden soll.

cookie ist eine Cookie-Instanz. request ist ein Objekt, das die in der Dokumentation für CookieJar.extract_cookies() definierte Schnittstelle implementiert.

CookiePolicy.return_ok(cookie, request)

Gibt einen booleschen Wert zurück, der angibt, ob ein Cookie an den Server zurückgegeben werden soll.

cookie ist eine Cookie-Instanz. request ist ein Objekt, das die in der Dokumentation für CookieJar.add_cookie_header() definierte Schnittstelle implementiert.

CookiePolicy.domain_return_ok(domain, request)

Gibt False zurück, wenn Cookies nicht zurückgegeben werden sollen, gegeben die Cookie-Domäne.

Diese Methode ist eine Optimierung. Sie erspart die Prüfung jedes Cookies mit einer bestimmten Domäne (was das Lesen vieler Dateien beinhalten könnte). Die Rückgabe von true von domain_return_ok() und path_return_ok() überlässt die gesamte Arbeit return_ok().

Wenn domain_return_ok() für die Cookie-Domäne true zurückgibt, wird path_return_ok() für den Cookie-Pfad aufgerufen. Andernfalls werden path_return_ok() und return_ok() für diese Cookie-Domäne nie aufgerufen. Wenn path_return_ok() true zurückgibt, wird return_ok() mit dem Cookie-Objekt selbst für eine vollständige Überprüfung aufgerufen. Andernfalls wird return_ok() für diesen Cookie-Pfad nie aufgerufen.

Beachten Sie, dass domain_return_ok() für jede Cookie-Domäne aufgerufen wird, nicht nur für die Request-Domäne. Beispielsweise kann die Funktion mit sowohl ".example.com" als auch "www.example.com" aufgerufen werden, wenn die Request-Domäne "www.example.com" ist. Dasselbe gilt für path_return_ok().

Das Argument request ist wie in der Dokumentation für return_ok() dokumentiert.

CookiePolicy.path_return_ok(path, request)

Gibt False zurück, wenn Cookies nicht zurückgegeben werden sollen, gegeben den Cookie-Pfad.

Siehe die Dokumentation für domain_return_ok().

Zusätzlich zur Implementierung der oben genannten Methoden müssen Implementierungen der CookiePolicy-Schnittstelle auch die folgenden Attribute bereitstellen, die angeben, welche Protokolle verwendet werden sollen und wie. Alle diese Attribute können zugewiesen werden.

CookiePolicy.netscape

Implementiert das Netscape-Protokoll.

CookiePolicy.rfc2965

Implementiert das RFC 2965-Protokoll.

CookiePolicy.hide_cookie2

Fügt den Anfragen keinen Cookie2-Header hinzu (die Anwesenheit dieses Headers zeigt dem Server an, dass wir RFC 2965-Cookies verstehen).

Der nützlichste Weg, eine CookiePolicy-Klasse zu definieren, ist die Ableitung von DefaultCookiePolicy und die Überschreibung einiger oder aller der oben genannten Methoden. CookiePolicy selbst kann als „Null-Policy“ verwendet werden, um das Setzen und Empfangen beliebiger und aller Cookies zu erlauben (dies ist wahrscheinlich nicht nützlich).

DefaultCookiePolicy-Objekte

Implementiert die Standardregeln für die Annahme und Rückgabe von Cookies.

Sowohl RFC 2965- als auch Netscape-Cookies werden abgedeckt. Die RFC 2965-Verarbeitung ist standardmäßig deaktiviert.

Der einfachste Weg, eine eigene Richtlinie bereitzustellen, besteht darin, diese Klasse zu überschreiben und ihre Methoden in Ihren überschriebenen Implementierungen aufzurufen, bevor Sie Ihre eigenen zusätzlichen Prüfungen hinzufügen

import http.cookiejar
class MyCookiePolicy(http.cookiejar.DefaultCookiePolicy):
    def set_ok(self, cookie, request):
        if not http.cookiejar.DefaultCookiePolicy.set_ok(self, cookie, request):
            return False
        if i_dont_want_to_store_this_cookie(cookie):
            return False
        return True

Zusätzlich zu den für die Implementierung der CookiePolicy-Schnittstelle erforderlichen Funktionen ermöglicht diese Klasse das Blockieren und Zulassen von Domänen für das Setzen und Empfangen von Cookies. Es gibt auch einige Strictness-Schalter, die es Ihnen ermöglichen, die eher lockeren Netscape-Protokollregeln etwas zu verschärfen (auf Kosten des Blockierens einiger harmloser Cookies).

Eine Blockierliste und eine Zulassungsliste für Domänen sind vorhanden (beide standardmäßig deaktiviert). Nur Domänen, die nicht in der Blockierliste und in der Zulassungsliste vorhanden sind (wenn die Zulassungsliste aktiv ist), nehmen am Setzen und Zurückgeben von Cookies teil. Verwenden Sie das Konstruktorargument blocked_domains und die Methoden blocked_domains() und set_blocked_domains() (und das entsprechende Argument und die Methoden für allowed_domains). Wenn Sie eine Zulassungsliste festlegen, können Sie sie wieder deaktivieren, indem Sie sie auf None setzen.

Domänen in Blockier- oder Zulassungslisten, die nicht mit einem Punkt beginnen, müssen mit der Cookie-Domäne übereinstimmen, um abgeglichen zu werden. Beispielsweise stimmt "example.com" mit einem Blocklisten-Eintrag von "example.com" überein, aber "www.example.com" nicht. Domänen, die mit einem Punkt beginnen, werden auch von spezifischeren Domänen abgeglichen. Beispielsweise stimmen sowohl "www.example.com" als auch "www.coyote.example.com" mit ".example.com" überein (aber "example.com" selbst nicht). IP-Adressen sind eine Ausnahme und müssen exakt übereinstimmen. Wenn beispielsweise blocked_domains "192.168.1.2" und ".168.1.2" enthält, wird 192.168.1.2 blockiert, 193.168.1.2 jedoch nicht.

DefaultCookiePolicy implementiert die folgenden zusätzlichen Methoden

DefaultCookiePolicy.blocked_domains()

Gibt die Sequenz der blockierten Domänen zurück (als Tupel).

DefaultCookiePolicy.set_blocked_domains(blocked_domains)

Setzt die Sequenz der blockierten Domänen.

DefaultCookiePolicy.is_blocked(domain)

Gibt True zurück, wenn domain auf der Blockierliste für das Setzen oder Empfangen von Cookies steht.

DefaultCookiePolicy.allowed_domains()

Gibt None oder die Sequenz der erlaubten Domänen zurück (als Tupel).

DefaultCookiePolicy.set_allowed_domains(allowed_domains)

Setzt die Sequenz der erlaubten Domänen oder None.

DefaultCookiePolicy.is_not_allowed(domain)

Gibt True zurück, wenn domain nicht auf der Zulassungsliste für das Setzen oder Empfangen von Cookies steht.

DefaultCookiePolicy Instanzen haben die folgenden Attribute, die alle aus den Konstruktorargumenten mit demselben Namen initialisiert werden und denen alle zugewiesen werden können.

DefaultCookiePolicy.rfc2109_as_netscape

Wenn true, fordert an, dass die CookieJar-Instanz RFC 2109-Cookies herabstuft (d. h. Cookies, die in einem Set-Cookie-Header mit einem Cookie-Versionsattribut von 1 empfangen werden) zu Netscape-Cookies, indem das Versionsattribut des Cookie-Objekts auf 0 gesetzt wird. Der Standardwert ist None, in welchem Fall RFC 2109-Cookies herabgestuft werden, wenn und nur wenn die RFC 2965-Verarbeitung deaktiviert ist. Daher werden RFC 2109-Cookies standardmäßig herabgestuft.

Allgemeine Strictness-Schalter

DefaultCookiePolicy.strict_domain

Erlaubt Websites nicht, Zwei-Komponenten-Domänen mit Top-Level-Domänen von Ländercodes wie .co.uk, .gov.uk, .co.nz usw. zu setzen. Dies ist alles andere als perfekt und keine Garantie für die Funktionalität!

RFC 2965-Protokoll Strictness-Schalter

DefaultCookiePolicy.strict_rfc2965_unverifiable

Folgt den RFC 2965-Regeln für nicht verifizierbare Transaktionen (normalerweise ist eine nicht verifizierbare Transaktion eine, die aus einer Umleitung oder einer Anfrage für ein Bild auf einer anderen Website resultiert). Wenn dies false ist, werden Cookies niemals auf der Grundlage der Verifizierbarkeit blockiert.

Netscape-Protokoll Strictness-Schalter

DefaultCookiePolicy.strict_ns_unverifiable

Wendet die RFC 2965-Regeln für nicht verifizierbare Transaktionen auch auf Netscape-Cookies an.

DefaultCookiePolicy.strict_ns_domain

Flags, die angeben, wie streng mit Domänenabgleichsregeln für Netscape-Cookies umgegangen werden soll. Siehe unten für akzeptable Werte.

DefaultCookiePolicy.strict_ns_set_initial_dollar

Ignoriert Cookies in Set-Cookie: Headern, deren Namen mit '$' beginnen.

DefaultCookiePolicy.strict_ns_set_path

Erlaubt nicht das Setzen von Cookies, deren Pfad nicht mit der Anfrage-URI übereinstimmt.

strict_ns_domain ist eine Sammlung von Flags. Sein Wert wird durch ODER-Verknüpfung gebildet (z. B. bedeutet DomainStrictNoDots|DomainStrictNonDomain, dass beide Flags gesetzt sind).

DefaultCookiePolicy.DomainStrictNoDots

Beim Setzen von Cookies darf der „Host-Präfix“ keinen Punkt enthalten (z. B. kann www.foo.bar.com kein Cookie für .bar.com setzen, da www.foo einen Punkt enthält).

DefaultCookiePolicy.DomainStrictNonDomain

Cookies, die kein domain-Cookie-Attribut explizit angegeben haben, können nur an eine Domäne zurückgegeben werden, die mit der Domäne übereinstimmt, die das Cookie gesetzt hat (z. B. werden spam.example.com keine Cookies von example.com zurückgegeben, die kein domain-Cookie-Attribut hatten).

DefaultCookiePolicy.DomainRFC2965Match

Beim Setzen von Cookies ist ein vollständiger RFC 2965-Domänenabgleich erforderlich.

Die folgenden Attribute werden zur Bequemlichkeit bereitgestellt und sind die nützlichsten Kombinationen der obigen Flags

DefaultCookiePolicy.DomainLiberal

Entspricht 0 (d. h. alle oben genannten Netscape-Domänen-Strictness-Flags sind deaktiviert).

DefaultCookiePolicy.DomainStrict

Entspricht DomainStrictNoDots|DomainStrictNonDomain.

Beispiele

Das erste Beispiel zeigt die häufigste Verwendung von http.cookiejar.

import http.cookiejar, urllib.request
cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
r = opener.open("http://example.com/")

Dieses Beispiel zeigt, wie eine URL über Ihre Netscape-, Mozilla- oder Lynx-Cookies geöffnet wird (geht von der Unix/Netscape-Konvention für den Speicherort der Cookie-Datei aus).

import os, http.cookiejar, urllib.request
cj = http.cookiejar.MozillaCookieJar()
cj.load(os.path.join(os.path.expanduser("~"), ".netscape", "cookies.txt"))
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
r = opener.open("http://example.com/")

Das nächste Beispiel veranschaulicht die Verwendung von DefaultCookiePolicy. Aktivieren Sie RFC 2965-Cookies, seien Sie strenger bei Domänen beim Setzen und Zurückgeben von Netscape-Cookies und blockieren Sie einige Domänen am Setzen von Cookies oder am Zurückgeben.

import urllib.request
from http.cookiejar import CookieJar, DefaultCookiePolicy
policy = DefaultCookiePolicy(
    rfc2965=True, strict_ns_domain=Policy.DomainStrict,
    blocked_domains=["ads.net", ".ads.net"])
cj = CookieJar(policy)
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
r = opener.open("http://example.com/")