Sendet jede Webanforderung die Browser-Cookies?

197

Sendet jede Webanforderung die Cookies des Browsers?

Ich spreche nicht von Seitenaufrufen, sondern von einer Anfrage nach einem Bild, einer .jsDatei usw.

Aktualisieren Wenn eine Webseite 50 Elemente enthält, sind dies 50 Anforderungen. Warum sollte es die gleichen Cookies für jede Anfrage senden, nicht zwischenspeichern oder wissen, dass es bereits vorhanden ist?

cookies

— mrblah
quelle

8

Ich denke nicht, dass Caching in dieser Situation möglich ist - wir sprechen über den Browser, der Daten an den Server sendet, nicht umgekehrt. Sie können aus vielen Gründen nicht sicher sagen, dass der Server "bereits" hat, nachdem der Benutzer eine Anfrage gesendet hat. Möglicherweise gibt es eine große Anzahl von Servern, die nicht miteinander kommunizieren. Der Server möchte (oder hat keinen Platz), um sich überhaupt an frühere Anforderungen zu erinnern. HTTP soll zustandslos sein. Jede Anfrage sollte unabhängig von den anderen sein. Aus diesem Grund müssen Cookies wie Authentifizierungsdaten bei jeder Anforderung gesendet werden.

— Ian Clelland

Ich erwähnte in einem Update meiner Antwort, warum Caching für Cookies keinen Sinn macht: stackoverflow.com/a/1336178/102960

— igorsantos07

197

Ja, solange sich die angeforderte URL in derselben Domäne und demselben Pfad befindet, die im Cookie definiert sind (und alle anderen Einschränkungen - sicher, nur http, nicht abgelaufen usw.), gilt das Cookie für jede Anforderung.

— Ian Clelland
quelle

103

Aus diesem Grund empfehlen Tools für die Seitengeschwindigkeit wie Google Page Speed oder Yahoo YSlow, statische Inhalte von einer separaten, Cookie-freien Domain bereitzustellen.

— Ceejayoz

Ich habe in meiner aktualisierten Antwort erwähnt, dass Inhalte aus einer separaten Domain bereitgestellt werden

— sollen

Stimmt es, dass der Browser Site2-Cookies sendet, wenn eine HTTP-Umleitung von Site1 zu Site2 erfolgt?

— Zeigeist

92

Wie andere bereits gesagt haben, wird der Host, der Pfad usw. des Cookies 50 Mal gesendet, wenn er den Einschränkungen entspricht.

Sie haben aber auch gefragt, warum: weil Cookies eine HTTP-Funktion sind und HTTP zustandslos ist. HTTP funktioniert so, dass der Server keinen Status zwischen Anforderungen speichert.

Tatsächlich kann der Server nicht genau erkennen, welcher Benutzer eine bestimmte Anfrage sendet. Hinter einem einzelnen Webproxy (und damit der IP-Adresse) können sich tausend Benutzer befinden. Wenn die Cookies nicht bei jeder Anfrage gesendet würden, hätte der Server keine Möglichkeit zu wissen, welcher Benutzer welche Ressource anfordert.

Schließlich hat der Browser keine Ahnung, ob der Server die Cookies benötigt oder nicht. Er weiß nur, dass der Server ihn angewiesen hat, das Cookie für jede Anfrage an foo.com zu senden. Manchmal benötigen Bilder sie (z. B. dynamisch generierte Benutzer), manchmal nicht, aber der Browser kann es nicht erkennen.

— derobert
quelle

1

Trifft dies auf HTTP 1.1 zu, bei dem es sich um ein Multiplexschema handelt? Das heißt, die Anforderungen werden in einer einzelnen TCP-Verbindung gebündelt. Natürlich wird jede Anfrage mit einer Kopie des angehängten Cookies empfangen. Wenn es jedoch um viele Übertragungsduplikationen geht, kann HTTP 1.1 optimiert werden. Obwohl ich nicht weiß, ob es tatsächlich so ist ...

— Chris Noe

1

Dann lautet das Problem "An welche Anforderungen wollte der Browser die Cookies anhängen?" Der Server legt die Richtlinie mit dem Cookie fest, um zu entscheiden, an welche Domänen und welche URL-Pfade das Cookie zurückgesendet werden soll, vergisst es dann jedoch. Sie benötigen eine Möglichkeit, um anzugeben, dass bestimmte Anforderungen in der Verbindung das Cookie enthalten haben und andere nicht. Das gibt es in HTTP / 1.1 definitiv nicht, außer indem sie explizit in jede Anfrage aufgenommen werden. Ehrlich gesagt wäre eine bessere (standardkompatible) Lösung zur Reduzierung der Bandbreite die clientseitige Kodierung von GZIP-Inhalten, aber das unterstützt noch niemand.

— Ian Clelland

1

@ Ian Clelland: Der Client muss die erste Nachricht senden, damit er nicht weiß, was der Server für die Accept-Encoding senden würde (wenn Server dieses Feld senden würden, sagt HTTP / 1.1 §14.3, dass es sich um einen Anforderungsheader handelt). Das Problem ist, dass es selbst auf demselben Server je nach URL variieren kann und sich im Laufe der Zeit ändern kann, sodass es nicht trivial wäre, es zum Laufen zu bringen.

— Derobert

1

@ Chris: Nein, Keepalive spart nur den Aufwand für das Einrichten / Herunterfahren von TCP-Verbindungen, das ist alles. Für jede Anfrage werden weiterhin vollständige Header gesendet. Pipelining (Senden mehrerer Anfragen ohne Warten auf die Antwort) kann jedoch sehr hilfreich sein. HTTP / 1.1 §8.1 enthält Details.

— Derobert

21

Ja. Jede Anfrage sendet die Cookies, die zur gleichen Domain gehören. Sie werden nicht zwischengespeichert, da HTTP zustandslos ist. Dies bedeutet, dass jede Anforderung ausreichen muss, damit der Server herausfindet, was damit zu tun ist. Angenommen, Sie haben Bilder, auf die nur bestimmte Benutzer zugreifen können. Sie müssen Ihr Auth-Cookie mit jeder dieser 50 Anfragen senden, damit der Server weiß, dass Sie es sind und nicht jemand anderes oder ein Gast aus dem Pool der Anfragen, die er erhält.

Allerdings werden Cookies aufgrund anderer Einschränkungen, die in den anderen Antworten erwähnt werden, wie z. B. HTTPS-Einstellung, Pfad oder Domäne, möglicherweise nicht gesendet. Besonders dort ist ein wichtiger Punkt zu beachten: Cookies werden nicht zwischen Domains geteilt. Dies hilft bei der Reduzierung der Größe von HTTP-Aufrufen für statische Dateien, wie z. B. die von Ihnen erwähnten Bilder und Skripte.
Beispiel: Sie haben 4 Cookies bei www.stackoverflow.com; Wenn Sie eine Anfrage an stellen www.stackoverflow.com/images/logo.png, werden alle diese 4 Cookies gesendet.
Wenn Sie dies jedoch anfordern stackoverflow.com/images/logo.png(beachten Sie die Änderung der Subdomain) oder images.stackoverflow.com/logo.png, sind diese 4 Cookies nicht vorhanden - möglicherweise jedoch diejenigen, die sich auf diese Domains beziehen.

Weitere Informationen zu Cookies und Bildern, die beispielsweise angefordert werden, finden Sie beispielsweise in diesem StackOverflow-Blogbeitrag .

— igorsantos07
quelle

10

Nein, nicht jede Anfrage sendet die Cookies. Dies hängt von der Cookie-Konfiguration und der Client-Server-Verbindung ab.

Wenn beispielsweise die secureOption Ihres Cookies auf gesetzt ist, truemuss es über eine sichere HTTPS-Verbindung übertragen werden. Wenn Sie diese Website mit HTTP-Protokoll sehen, werden diese Cookies nicht von Browsern gesendet, da das sichere Flag wahr ist.

— Iman Sedighi
quelle

7

Cookie hat eine "Pfad" -Eigenschaft. Wenn "path = /", lautet die Antwort Ja.

— neoedmund
quelle

Ja, Sie können Ihre Website- / App-Struktur so organisieren, dass alle URLs, für die Cookies erforderlich sind, dünn /app/oder ähnlich sind. Dadurch bleibt die Portabilität erhalten, ohne dass separate Subdomains erforderlich sind , um redundanten Overhead zu vermeiden. Oder Sie könnten zunächst die jetzt nutzlose Google Analytics fallen lassen. Ich habe so lange Cookie-Header gesehen, dass ich mich frage, ob meine Großmutter sie gestrickt hat.

— Jake

7

3 Jahre sind vergangen

Es gibt noch einen weiteren Grund, warum ein Browser keine Cookies sendet. Sie können crossOriginIhrem <script>Tag ein Attribut und den Wert zu hinzufügen "anonymous". Dadurch wird verhindert, dass Cookies an den Zielserver gesendet werden. In 99,9% der Fälle handelt es sich bei Ihren Javaskripten um statische Dateien, und Sie generieren diesen JS-Code nicht basierend auf den Cookies der Anfrage. Wenn Sie 1 KB Cookies haben und 200 Ressourcen auf Ihrer Seite haben, lädt Ihr Benutzer 200 KB hoch. Dies kann bei 3G einige Zeit dauern und hat keine Auswirkungen auf die Ergebnisseite. Besuchen Sie das HTML-Attribut: crossorigin als Referenz.

— Gilm
quelle

Bitte erkläre.

— Jake

4

@Jake Sie können Ihrem <script> -Tag ein crossOrigin-Attribut und den Wert "anonym" hinzufügen. Dadurch wird verhindert, dass Cookies an den Zielserver gesendet werden. In 99,9% der Fälle handelt es sich bei Ihren Javaskripten um statische Dateien, und Sie generieren diesen JS-Code nicht basierend auf den Cookies der Anfrage. Wenn Sie 1 KB Cookies haben und 200 Ressourcen auf Ihrer Seite haben, lädt Ihr Benutzer 200 KB hoch. Dies kann bei 3G einige Zeit dauern und hat keine Auswirkungen auf die Ergebnisseite. Besuchen Sie developer.mozilla.org/en-US/docs/Web/HTML/… als Referenz.

— Gilm

4

Ich weiß, dass dies ein alter Thread ist. Ich habe jedoch gerade festgestellt, dass die meisten Browser keine Cookies für eine Domain senden, wenn Sie einen nachgestellten Punkt hinzufügen. Zum Beispiel http://example.com.erhalten keine Cookies gesetzt für .example.com. Apache hingegen behandelt sie als denselben Host. Ich finde dies nützlich, um die domänenübergreifende Nachverfolgung für die von mir eingeschlossenen externen Ressourcen zu erschweren. Sie können sie jedoch auch aus Leistungsgründen verwenden. Beachten Sie, dass dies die Validierung von httpsZertifikaten bremst . Ich habe einige Tests mit Browsershots und meinen eigenen Geräten durchgeführt. Der Hack funktioniert in fast allen Browsern, mit Ausnahme von Safari (Mobil und Desktop), bei dem Cookies in der Anfrage enthalten sind.

— Gellweiler
quelle

Wie erschwert es "die domänenübergreifende Nachverfolgung für externe Ressourcen, die ich einbeziehe"? Sprechen Sie über Farcebook Like und solche Widgets, von denen wir wissen, dass sie das Durchsuchen von versehentlich noch angemeldeten Benutzern verfolgen?

— Jake

Ja. Dies wird es schwieriger machen, da die meisten Browser die Cookies nicht mitsenden. Wenn Sie also beispielsweise etwas von google.com hinzufügen und bei Google angemeldet sind, kann Google die beiden Anforderungen nicht verknüpfen. Dies ist nicht garantiert schwierig, einige Browser haben die Cookies trotzdem gesendet und es gibt weniger zuverlässige und weniger verwendete Methoden, um Benutzer (wie IP-Adressen) zu identifizieren, die noch funktionieren. Der größte Nachteil ist, dass Sie HTTPS nicht verwenden können, was es heute unbrauchbar macht.

— Gellweiler

0

Kurze Antwort ist Ja. Die folgenden Zeilen stammen aus der JS-Dokumentation

Cookies wurden früher für die allgemeine clientseitige Speicherung verwendet. Während dies legitim war, als sie die einzige Möglichkeit waren, Daten auf dem Client zu speichern, wird jetzt empfohlen, moderne Speicher-APIs zu verwenden. Bei jeder Anfrage werden Cookies gesendet, damit die Leistung beeinträchtigt werden kann (insbesondere bei mobilen Datenverbindungen).

— Yashwin Munsadwala
quelle