Wann werden Cookies gesendet?

[Mario Steinko]

Hi!

Wenn ich von der Domain www.example.com ein Cookie setzen lasse werden bei allen zukünftigen Requests die Cookies mitgesendet, auch für statische Dokumente wie Bildern oder Java Script Dateien.
Werden die Cookies bei der subdomain static.example.com auch noch mitgesendet?
oder brauch ich echt noch ne andre Domain, z.B. domain2.com um statische Inhalte schneller abzurufen?

danke
Mario

[Texter mit x]

Was Cookies angeht bin ich Anfänger aber hat "Path" dafür keine Auswirkung?

[Texter mit x]

PS: http://de.php.net/manual/de/function.setcookie.php siehe dort unter domain

Warum hast Du das nicht gefunden?

[Cheatah]

Hi,

Was Cookies angeht bin ich Anfänger aber hat "Path" dafür keine Auswirkung?

das ist völlig korrekt, "Path" hat dafür keine Auswirkung. "Path" bezieht sich auf den Pfad.

Cheatah

[Dennis]

Hi Mario,

Wenn ich von der Domain www.example.com ein Cookie setzen lasse werden bei allen zukünftigen Requests die Cookies mitgesendet, auch für statische Dokumente wie Bildern oder Java Script Dateien.
Werden die Cookies bei der subdomain static.example.com auch noch mitgesendet?

Das kommt darauf an, wie du das Cookie setzt. Wenn du es für die Domain „example.com” setzt, dann wird es auch nur für diese Domain mitgesendet (und übrigens nicht für „www.example.com”). Wenn es ein Cookie für die Domain „.example.com” setzt, dann wird es außer für diese Domain auch für alle Subdomains unter ebendieser Domain mitgesendet.

oder brauch ich echt noch ne andre Domain, z.B. domain2.com um statische Inhalte schneller abzurufen?

Ich sehe keinen Zusammenhang zwischen Cookies und der Geschwindigkeit, was den Abruf statischer Seiten anbelangt. Zumindest nicht bei den Datenmengen, die man üblicherweise in Cookies speichert. Solltest du derart große Datenmengen in Cookies ablegen, dass das Abrufen statischer Seiten zu einem Traffic-Problem für dich wird, solltest du dein Konzept überdenken und prüfen, ob du nicht vielleicht auf DOM Storage (ab Firefox 2.0 & IE 8) umsteigen kannst.

Viele Grüße,
  ~ Dennis.

[Edgar Ehritt]

Hallo Dennis,

oder brauch ich echt noch ne andre Domain, z.B. domain2.com um statische Inhalte schneller abzurufen?
Ich sehe keinen Zusammenhang zwischen Cookies und der Geschwindigkeit, was den Abruf statischer Seiten anbelangt.

das erscheint mir auch unwahrscheinlich, jedoch...

Zumindest nicht bei den Datenmengen, die man üblicherweise in Cookies speichert. Solltest du derart große Datenmengen in Cookies ablegen, dass das Abrufen statischer Seiten zu einem Traffic-Problem für dich wird, solltest du dein Konzept überdenken und prüfen, ob du nicht vielleicht auf DOM Storage (ab Firefox 2.0 & IE 8) umsteigen kannst.

...sehe ich das etwas anders - ja ganz im Gegenteil, ist es ein Feinschliff eines Konzepts, sich auch mal um solche Sachen zu scheren.

Rufe ich beispielsweise die Forumshauptseite ab, werden in Folge dieser Anfrage 18 weitere Anfragen gestartet (CSS, JS, grafische Medien). Sagen wir mal, alle Medien würden von einer Domain bezogen. Selbst wenn ich dann in einem Cookie 100 Bytes Datenanteil habe, wäre dies im Beispiel dieses Forums ein sinnloser Datentransfer von gut 2 kB für, nochmals angemerht, nur ein willentlich abgerufenes Dokument. Bei dem zum Zeitpunkt dieses Postings gerade 56 kB großen Dokument, sind das etwa 4%. Das will ich jedenfalls nach der Wahl nicht als Mehrwertsteuererhöhung zahlen müssen, weil es so gering ist. ;)

Der Ansatz Cookies nach Domains oder Verzeichnissen zu vergeben, macht also Sinn das Konzept kann daher völlig außer Acht bleiben.

Gruß aus Berlin!
eddi

[Beat]

Rufe ich beispielsweise die Forumshauptseite ab, werden in Folge dieser Anfrage 18 weitere Anfragen gestartet (CSS, JS, grafische Medien). Sagen wir mal, alle Medien würden von einer Domain bezogen. Selbst wenn ich dann in einem Cookie 100 Bytes Datenanteil habe, wäre dies im Beispiel dieses Forums ein sinnloser Datentransfer von gut 2 kB für, nochmals angemerht, nur ein willentlich abgerufenes Dokument. Bei dem zum Zeitpunkt dieses Postings gerade 56 kB großen Dokument, sind das etwa 4%. Das will ich jedenfalls nach der Wahl nicht als Mehrwertsteuererhöhung zahlen müssen, weil es so gering ist. ;)

Und auch dir sollte klar sein, dass ein normales Cookie bestenfalls 15% der Header Message ausmacht. Du müsstest also deine Überlegung ausweiten auf alle Headerteile, bis du vom Server den Invalidenschein ausgestellt erhältst.

Im Übrigen ist dort, wo Cookies eingesetzt werden, bei vernünftigem Caching-Einsatz auch der Cookieversandt nur bei Browsern der Fall, die man als Triebtäter bezeichnen müsste.

mfg Beat

[Pragma]

Und auch dir sollte klar sein...

Auch Dir sollte klar sein(HRMPF), dass der Upstream gewöhnlich ein weitaus knapperes Gut als der Downstream darstellt. Kleinvieh macht hier also potentiell noch mehr Mist.

bei vernünftigem Caching-Einsatz auch

Stimmt: alle Ressourcen signieren, Last Modified & Co wegnehmen.. und man kann einiges sparen. Das hat aber mit der Cookie Frage zunächst nix zu tun.

Außerdem ist das nur ein Vorteil der Auslagerung statischer Ressourcen, aber was red ich:

http://developer.yahoo.com/performance/rules.html

[Edgar Ehritt]

Hallo erstmal!

Rufe ich beispielsweise die Forumshauptseite ab, werden in Folge dieser Anfrage 18 weitere Anfragen gestartet (CSS, JS, grafische Medien). Sagen wir mal, alle Medien würden von einer Domain bezogen. Selbst wenn ich dann in einem Cookie 100 Bytes Datenanteil habe, wäre dies im Beispiel dieses Forums ein sinnloser Datentransfer von gut 2 kB für, nochmals angemerht, nur ein willentlich abgerufenes Dokument. Bei dem zum Zeitpunkt dieses Postings gerade 56 kB großen Dokument, sind das etwa 4%. Das will ich jedenfalls nach der Wahl nicht als Mehrwertsteuererhöhung zahlen müssen, weil es so gering ist. ;)

Und auch dir sollte klar sein, dass ein normales Cookie bestenfalls 15% der Header Message ausmacht. Du müsstest also deine Überlegung ausweiten auf alle Headerteile, bis du vom Server den Invalidenschein ausgestellt erhältst.

Im Übrigen ist dort, wo Cookies eingesetzt werden, bei vernünftigem Caching-Einsatz auch der Cookieversandt nur bei Browsern der Fall, die man als Triebtäter bezeichnen müsste.

Deine Nachricht besteht aus drei Sätzen. Nicht einen habe ich verstanden. Erkläre Deine Argumente anhand von Belegen, dass man sie prüfen und gegebenenfalls diskutieren kann!

Wie kommst Du zu 15 %?
Was meinst Du mit "Header Message"?
Was meinst Du in diesem Zusammenhang mit "Headerteile"?
Server stellen keine Invalidenscheine aus, was meint Dein Hip-Hop-Slang?
Dynamische Seiten werden, aufgrund ihrer Eigenschaft "dynamisch" allermeist explizit als "no-cache" übermittelt. Was soll mir also Deine Andeutung sagen?

Gruß aus Berlin!
eddi

[Beat]

Deine Nachricht besteht aus drei Sätzen. Nicht einen habe ich verstanden. Erkläre Deine Argumente anhand von Belegen, dass man sie prüfen und gegebenenfalls diskutieren kann!

Ich schaue mir den Header Request an und sehe dort, dass _ein_ Cookie in der ganzen Request Message nur ca. 15% ausmacht.

Wie kommst Du zu 15 %?

Eine Schätzung. Trage irgend etwas zwischen 10 und 20% ein, das ist UA-spezifisch.

Was meinst Du in diesem Zusammenhang mit "Headerteile"?

zum Beispiel Accept und Accept-Language

Server stellen keine Invalidenscheine aus, was meint Dein Hip-Hop-Slang?

Ein Request bedarf gewisser minimaler Angaben unterhalb dessen ein Request sonst nicht mehr bearbeitet wird.

Dynamische Seiten werden, aufgrund ihrer Eigenschaft "dynamisch" allermeist explizit als "no-cache" übermittelt. Was soll mir also Deine Andeutung sagen?

Ja, dein Einwand war ja motiviert durch die statischen Ressourcen wie Bilder etc...

Ich sehe da kein Problem bei Cookies.
Es gibt allerdings einen Grund, Cookies möglichst auf die Domain und wenn nötig auf einen Pfad zu beschränken, nämlich wenn du unter der gleichen Domain andere Applikationen betreibst, die aber ihre eigenen Cookies (manchmal mit gleichem namen) haben.
Es ist eher ein betriebslogisches als ein Transvervolume betreffendes Problem.

mfg Beat

[Edgar Ehritt]

Re:

Deine Nachricht besteht aus drei Sätzen. Nicht einen habe ich verstanden. Erkläre Deine Argumente anhand von Belegen, dass man sie prüfen und gegebenenfalls diskutieren kann!

Ich schaue mir den Header Request an und sehe dort, dass _ein_ Cookie in der ganzen Request Message nur ca. 15% ausmacht.

Wie kommst Du zu 15 %?

Eine Schätzung. Trage irgend etwas zwischen 10 und 20% ein, das ist UA-spezifisch.

Cookies werden nach RFC 2965 bzw. RFC 2109 versandt. Nichts aber auch rein gar nichts ist daran spezifisch. Alles ist produktübergreifend standardisiert. Was haben diese 15 % im Bezug worauf nun für eine Relevanz? Es ist an der Zeit, Deine erste Aussage in einem Gesamtzusammenhang zu präsentieren - stattdessen bekomme ich weitere zusammenhanglose Brocken vor die Füße geworfen. Ich finde das dreist. Wenn ich mich irre, dann hilf mir doch und mache es mir verständlich!

Was meinst Du in diesem Zusammenhang mit "Headerteile"?

zum Beispiel Accept und Accept-Language

Warum sollte ich meine Überlegungen auf Accept oder Accept-Language ausweiten? Ein Accept-Headers ist für den Abruf eines Stylesheets genauso überflüssig wie ein Assept-Language-Header. Als Webanwendungsentwickler kann ich dies mit serverseitigen Techniken nicht beeinflussen. Einen unnötig gesendeten Cookie jedoch schon. Nach wie vor ist mir völlig unklar, was Du mit Deinem zweiten Satz der ursprünglichen Nachicht eigentlich meinst.

Server stellen keine Invalidenscheine aus, was meint Dein Hip-Hop-Slang?

Ein Request bedarf gewisser minimaler Angaben unterhalb dessen ein Request sonst nicht mehr bearbeitet wird.

Richtig. Für die HTTP-Version 1.1 ist das im Regelfall einer GET-Anfrage die Anfragezeile und der Host-Header. Was hat das jetzt mit Set-Cookie-, Cookie-, Accept- oder Accept-Language-Header zutun? Du schriebst immer noch absolut schleierhaft. Lies am besten RFC 2616 und lass uns dann weiter reden!

Dynamische Seiten werden, aufgrund ihrer Eigenschaft "dynamisch" allermeist explizit als "no-cache" übermittelt. Was soll mir also Deine Andeutung sagen?

Ja, dein Einwand war ja motiviert durch die statischen Ressourcen wie Bilder etc...

Was passiert denn wenn, sagen wir, der Firefox eine statische Ressource wie ein Bild im Cache hat und in einer anderen Ressource darauf referenziert wird?

GET /logo.gif HTTP/1.1
Host: src.selfhtml.org
User-Agent: Firefox/3.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: de,de-de;q=0.8,de-at;q=0.6,en;q=0.4,en-us;q=0.2
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Thu, 01 Jan 2009 19:13:06 GMT
If-None-Match: "97dae-886-45f709d3f7480"
Cache-Control: max-age=0

HTTP/1.1 304 Not Modified
Date: Fri, 18 Sep 2009 10:09:00 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=15, max=99
Etag: "97dae-886-45f709d3f7480"
Expires: Fri, 25 Sep 2009 10:09:00 GMT
Cache-Control: max-age=604800, public

Es wird, ob Du nun besondere Cache-Vorkehrungen, wie aus den obenstehenden Headern ersichtlich, unternimmst oder nicht, jedenfalls eine Anfrage an den Server gestellt. Der Server antwortet mit Status 304 und es werden keine Nutzdaten übermittelt. Somit sieht die Bilanz für jedes noch so kleine Cookie noch schlechter aus. Das aber hatte Pragma schon erfolglos angedeutet.

Ich sehe da kein Problem bei Cookies.

Ist okay, nur argumentiere dann vernünftig, insbesondere verständlich mit jemanden, der dem nicht zustimmt.

Solltest Du in der nächsten Nachricht Dein Gewurstel nicht endgültig aufgegeben haben und Dich verständlich und informiert ausdrücken, war es das von mir aus.

Gruß aus Berlin!
eddi

[Beat]

Es wird, ob Du nun besondere Cache-Vorkehrungen, wie aus den obenstehenden Headern ersichtlich, unternimmst oder nicht, jedenfalls eine Anfrage an den Server gestellt.

Das ist absoluter Quatsch und gibt keineswegs die Wirklichkeit auf meinem Server mit meinem (oder der überwiegenden Zahl der) Browser wieder.
Ein neuer Request wird erst getätigt nach Ablauf der expire Frist.
Ein browser kann eine Anfrage dennoch starten, wenn die Expirefrist besonders lang ist. (Ich denke 24H ist da so ein Wert).
Wir reden aber nicht über einmalig angeforderte Ressourcen, sondern von Ressourcen, die ein Browser immer wieder in einem oder verschiedenen Dokumenten in kurzen Intervallen einbauen muss.

Solches Verhalten, dass Browser trotz nicht überschrittener kurzer Cache-Frist immer wieder anfragen senden, gehört in den Bereich notorischer Triebtäter, sprich Browser, die ihren Cache deaktiviert haben.

mfg Beat

[Edgar Ehritt]

Re:

Es wird, ob Du nun besondere Cache-Vorkehrungen, wie aus den obenstehenden Headern ersichtlich, unternimmst oder nicht, jedenfalls eine Anfrage an den Server gestellt.

Das ist absoluter Quatsch und gibt keineswegs die Wirklichkeit auf meinem Server mit meinem (oder der überwiegenden Zahl der) Browser wieder.
Ein neuer Request wird erst getätigt nach Ablauf der expire Frist.

Ach hättest Du doch vorher mit dem Firefox getestet, Dir wäre die Wirklichkeit, in dessen Einsicht Du Dich wähnst, gewahr geworden. Dein Server sendet dank Fehlkonfiguration RFC-widrig nicht mal einen Vary-Header. Raum rede ich also mit Dir?

Ein browser kann eine Anfrage dennoch starten, wenn die Expirefrist besonders lang ist. (Ich denke 24H ist da so ein Wert).

Was Du denkst, ist der RFC egal. Du warst aufgefordert, Dein "Denken" in Wissen zu überführen!

Wir reden aber nicht über einmalig angeforderte Ressourcen, sondern von Ressourcen, die ein Browser immer wieder in einem oder verschiedenen Dokumenten in kurzen Intervallen einbauen muss.

Wie oft muss ich jetzt die Header hier hineinkopieren, bist Du begreifst, weil die Header für jemanden, der Ahnung von der Materie hat, dies deutlichst zeigen, dass wir tatsächlich nicht von einmalig angeforderten Ressourcen reden. Du unterstellst es mir einfach ohne Ahnung zu haben, ohne irgend ein Beleg für Dein Denken, Glauben, Gefühl vorgetragen zu haben.

Solches Verhalten, dass Browser trotz nicht überschrittener kurzer Cache-Frist immer wieder anfragen senden, gehört in den Bereich notorischer Triebtäter, sprich Browser, die ihren Cache deaktiviert haben.

Nein, beat, es reicht bereits aus, dass der Cache voll ist. Deaktivieren muss ich nichts.

Da nunmehr klar ist, was genau Du alles meintest, danke ich für Dein Interesse an der Materie.

Gruß aus Berlin!
eddi