wo werden zu lange Cookies abgeschnitten?

[Andreas-Lindig]

hallo Forum,

wenn ein Cookie voll ist, also 4kb erreicht hat, dann wird ja der Überschuss an Daten abgeschnitten. Nur wo: vorn oder hinten? Und wo ist eigentlich vorn und wo hinten?
Ich schreibe für mein Forum-Projekt die ID's bereits gelesener Beiträge in ein Cookie, damit ich sie auf der Seite für den User auszeichnen kann. Und irgendwann sind es halt so viele, daß welche raus müssen. Ich würde dann gern die ältesten, also die mit der kleinsten Nummer löschen lassen. Kann ich das beeinflussen?

Gruß, Andreas
--
http://forum.andeas-lindig.deGruß, Andreas

[Chris (C)]

Hi Selferaußen,

der datenblock eines Cookies ist frei nutzbar. Das heißt, dass Du die Datenstruktur selber festlegen musst - also von der Modellierung bis zur Serialisierung runter.

Man kann für solche Zwecke gut

$datenblock_aus_cookie = base64_encode(serialize($datenarray));

benutzen. Und nach dem wiederauslesen des Cookies natürlich das ganze rückwärts, also

$datenarray = unserialize(base64_decode($datenblock_aus_cookie));

Anhand der Indexe im Array kannst Du dann die unliebsamen Elemente rausschießen: unset($datenarray[$index]);

Grüße

Chris (C)

[Philipp Hasenfratz]

Halihallo Andreas

wenn ein Cookie voll ist, also 4kb erreicht hat, dann wird ja der Überschuss an Daten abgeschnitten. Nur wo: vorn oder hinten? Und wo ist eigentlich vorn und wo hinten?

Laut RFC http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html wird über den
Ort IMHO nichts ausgesagt. Die 4kb sind "SHOULD":

---
   User agents created for specific purposes or for limited-capacity devices should provide at least 20 cookies of 4096 bytes, to ensure that the user can interact with a session-based origin server.
---

Du kannst nicht davon ausgehen, dass der Client wirklich 4kb speichert.

Ich schreibe für mein Forum-Projekt die ID's bereits gelesener Beiträge in ein Cookie, damit ich sie auf der Seite für den User auszeichnen kann. Und irgendwann sind es halt so viele, daß welche raus müssen. Ich würde dann gern die ältesten, also die mit der kleinsten Nummer löschen lassen. Kann ich das beeinflussen?

Ich würde raten diese serverseitig zu speichern. Andernfalls, speichere sie in zeitlich
aufsteigender Reihenfolge im Cookie und lösche ggf. alle Bytes nach dem 4096-ten.

Viele Grüsse

Philipp

[Sönke Tesch]

wenn ein Cookie voll ist, also 4kb erreicht hat, dann wird ja der Überschuss an Daten abgeschnitten. Nur wo: vorn oder hinten? Und wo ist eigentlich vorn und wo hinten?

Hinten ist am Ende der Zeichenkette, die Du als Cookie verschickst. Du kannst mit gutem Gewissen davon ausgehen, daß wenn abgeschnitten wird, dies am Ende passiert. Dieses Verhalten ist a) sinnvoll und b) einfacher umzusetzen, denn in jedem Fall liest der Browser eine Zeichenkette Byte für Byte vom Anfang her ein. Es ist einfacher, noch während des Lesens irgendwo "Stopp" zu sagen (wenn der reservierte Speicher voll ist), als bis zum (unbekannten) Ende weiter zu lese, dabei möglicherweise immer wieder Speicher reservieren zu müssen und dann den bereits gelesenen Anfang wieder abzuschnippeln.

Du kannst nicht davon ausgehen, dass der Client wirklich 4kb speichert.

..wobei das natürlich nichtsdestotrotz richtig ist.

Ich schreibe für mein Forum-Projekt die ID's bereits gelesener Beiträge in ein Cookie, damit ich sie auf der Seite für den User auszeichnen kann.

Ich würde raten diese serverseitig zu speichern.

Auch nicht immer glücklich. Man hat zwar die Daten unter Kontrolle, dafür sammeln sich aber mit der Zeit haufenweise Karteileichen an. Bei Cookienutzung muß man sich darum nicht kümmern.

Andernfalls, speichere sie in zeitlich
aufsteigender Reihenfolge im Cookie und lösche ggf. alle Bytes nach dem 4096-ten.

Wenn er sie zeitlich aufsteigend speichert, verliert er die neuesten Beiträge am Ende. Also zeitlich absteigend, die neuesten zuerst, speichern.

Es sollte weiterhin darauf geachtet werden, daß jede Beitragsnummer mit einem Trennzeichen abgeschlossen wird. Da die 4k-Grenze wie gesagt auch sonstwo liegen kann, hat man keinerlei Möglichkeit festzustellen, ob die letzte Nummer vollständig ist - es sei denn man verlangt, daß auch die letzte Nummer im Cookie mit dem Trennzeichen endet. Problembeispiel: "123;456;78", ist die letzte Nummer nun die 78 oder eine abgeschnittene 789?

Last but not least (und natürlich durchaus ein Argument für serverseitige Speicherung): 4k können bei der angedachten Nutzung sehr schnell sehr voll sein. Der Bereich lässt sich effektiver nutzen, wenn man statt einfachem Dezimaltext (mit den Zeichen 0 bis 9) die Basis erweitert und das komplette Alphabet hinzunimmt.
Die Problematik sollte bekannt sein: Die binäre Darstellung mit dem Ziffernvorrat 0 und 1 ist um ein Vielfaches länger als die Dezimal- oder Hexadezimaldarstellung: Binär 11111111 entspricht Dezimal 255 entsprich Hex FF - derselbe Wert, aber fünf bzw. sechs Zeichen weniger, je nach Basis 2, 10 oder 16. Mit dem Alphabet kann man die Basis auf 62 (Ziffern 0-9 plus 26 Buchstaben in groß und klein) erweitern und spart noch ein wenig Platz.

Gruß,
  soenk.e

[Philipp Hasenfratz]

Halihallo Sönke

Ich würde raten diese serverseitig zu speichern.
Auch nicht immer glücklich. Man hat zwar die Daten unter Kontrolle, dafür sammeln sich aber mit der Zeit haufenweise Karteileichen an. Bei Cookienutzung muß man sich darum nicht kümmern.

Ja.

Andernfalls, speichere sie in zeitlich
aufsteigender Reihenfolge im Cookie und lösche ggf. alle Bytes nach dem 4096-ten.
Wenn er sie zeitlich aufsteigend speichert, verliert er die neuesten Beiträge am Ende. Also zeitlich absteigend, die neuesten zuerst, speichern.

*grrr* ;)

Last but not least (und natürlich durchaus ein Argument für serverseitige Speicherung): 4k können bei der angedachten Nutzung sehr schnell sehr voll sein. Der Bereich lässt sich effektiver nutzen, wenn man statt einfachem Dezimaltext (mit den Zeichen 0 bis 9) die Basis erweitert und das komplette Alphabet hinzunimmt.
Die Problematik sollte bekannt sein: Die binäre Darstellung mit dem Ziffernvorrat 0 und 1 ist um ein Vielfaches länger als die Dezimal- oder Hexadezimaldarstellung: Binär 11111111 entspricht Dezimal 255 entsprich Hex FF - derselbe Wert, aber fünf bzw. sechs Zeichen weniger, je nach Basis 2, 10 oder 16. Mit dem Alphabet kann man die Basis auf 62 (Ziffern 0-9 plus 26 Buchstaben in groß und klein) erweitern und spart noch ein wenig Platz.

Äm, Sönke, würdest du nicht lieber einfach zwei Cookies senden wollen?
Pro Domain 30 Cookies, 4096 Bytes/Cookie, macht 120kb, hm, schon akzeptabel. Aber Achtung

• um dir gleich das Gegenargument vornwegzunehmen - bei mehr als 300 Cookies _könnten_
  insgesamt wird der jeweils am längsten nicht gebrauchte verschreddert, sprich: Es könnte
  den Cookie Nr. 17/30 treffen, der eine beträchtliche Lücke in die 120kb Daten frisst.
  Dieses Vorgehen ist IMHO nicht zu empfehlen.

Viele Grüsse

Philipp

[Sönke Tesch]

Andernfalls, speichere sie in zeitlich
aufsteigender Reihenfolge im Cookie und lösche ggf. alle Bytes nach dem 4096-ten.
Wenn er sie zeitlich aufsteigend speichert, verliert er die neuesten Beiträge am Ende. Also zeitlich absteigend, die neuesten zuerst, speichern.

*grrr* ;)

Dein Lüfter röhrt ;)

Last but not least (und natürlich durchaus ein Argument für serverseitige Speicherung): 4k können bei der angedachten Nutzung sehr schnell sehr voll sein. Der Bereich lässt sich effektiver nutzen, wenn man statt einfachem Dezimaltext (mit den Zeichen 0 bis 9) die Basis erweitert und das komplette Alphabet hinzunimmt.

Äm, Sönke, würdest du nicht lieber einfach zwei Cookies senden wollen?

Wenn mir eine Seite mehr als einen Cookie andrehen will, krieg ich 'ne Krise :) Nein, ernsthaft: Man kann natürlich mehrere Cookies setzen, nur stellt sich da die Frage wo die Trennung der Daten geschehen soll. Man müsste erstmal eine Logik entwickeln, die feststellt, wieviele Daten der Browser denn überhaupt pro Cookie annimmt - wäre mir etwas zu aufwendig.

Pro Domain 30 Cookies, 4096 Bytes/Cookie, macht 120kb, hm, schon akzeptabel.

Als Speicherplatz mag das akzeptabel sein, aber möchtest Du bei jeder einzelnen Anfrage an den Server 120 kByte bis schlimmstenfalls 240 kByte (die alten Cookies komplett zum Server, neue Cookies wieder zurück) durch die Leitung jagen? Ein klein wenig haushalten sollte man mit den Cookies vielleicht doch. :)

Mmh, wenn ich's mir recht überlege, hat die Speicherung auf dem Server doch noch einen nicht zu unterschätzenden Vorteil..

Gruß,
  soenk.e

[Philipp Hasenfratz]

Halihallo Sönke

*grrr* ;)
Dein Lüfter röhrt ;)

oder mein Hirn von Überhitzung... ;)

Wenn mir eine Seite mehr als einen Cookie andrehen will, krieg ich 'ne Krise :) Nein, ernsthaft: Man kann natürlich mehrere Cookies setzen, nur stellt sich da die Frage wo die Trennung der Daten geschehen soll. Man müsste erstmal eine Logik entwickeln, die feststellt, wieviele Daten der Browser denn überhaupt pro Cookie annimmt - wäre mir etwas zu aufwendig.

Du hast ja behauptet, dass Cookes trotz fehlendem MUST im Standard 4096-Bytes
akzeptieren ;)

Pro Domain 30 Cookies, 4096 Bytes/Cookie, macht 120kb, hm, schon akzeptabel.
Als Speicherplatz mag das akzeptabel sein, aber möchtest Du bei jeder einzelnen Anfrage an den Server 120 kByte bis schlimmstenfalls 240 kByte (die alten Cookies komplett zum Server, neue Cookies wieder zurück) durch die Leitung jagen? Ein klein wenig haushalten sollte man mit den Cookies vielleicht doch. :)

Schlimmer noch: Bei fehlendem Path wird dies bei jedem noch so kleinen Bildchen
passieren. Wie man meiner Signatur leicht entnehmen kann bin ich gegen Redundanz und
somit in den meisten Fällen auch gegen Cookies :)
Ernsthaft: Entweder sollen Cookies über path eingeschränkt werden, oder sie sollten so
klein wie möglich gehalten werden => keine Nutzdaten sondern referenzielle Information
für den Server.

Mmh, wenn ich's mir recht überlege, hat die Speicherung auf dem Server doch noch einen nicht zu unterschätzenden Vorteil..

Aha! ;)

Viele Grüsse

Philipp

[Sönke Tesch]

Du hast ja behauptet, dass Cookes trotz fehlendem MUST im Standard 4096-Bytes akzeptieren ;)

Nein, eigentlich nicht. Falls doch: Ich distanziere mich von allem und jedem, denn das Landgericht Hamburg blafasel... ;)

Mmh, wenn ich's mir recht überlege, hat die Speicherung auf dem Server doch noch einen nicht zu unterschätzenden Vorteil..

Aha! ;)

Pöh! .]

Schönen Abend,
  soenk.e

[wahsaga]

hi,

Hinten ist am Ende der Zeichenkette, die Du als Cookie verschickst. Du kannst mit gutem Gewissen davon ausgehen, daß wenn abgeschnitten wird, dies am Ende passiert. Dieses Verhalten ist a) sinnvoll und b) einfacher umzusetzen, denn in jedem Fall liest der Browser eine Zeichenkette Byte für Byte vom Anfang her ein. Es ist einfacher, noch während des Lesens irgendwo "Stopp" zu sagen (wenn der reservierte Speicher voll ist), als bis zum (unbekannten) Ende weiter zu lese, dabei möglicherweise immer wieder Speicher reservieren zu müssen und dann den bereits gelesenen Anfang wieder abzuschnippeln.

evtl. entdeckt er bei diesem versuch sogar einen neuen buffer overflow im internet explorer - "festplatte formatieren durch setzen eines cookies!"

wir dürfen gespannt sein ...

gruss,
wahsaga

[Andreas-Lindig]

Hallo Sönke,

Hinten ist am Ende der Zeichenkette, die Du als Cookie verschickst. Du kannst mit gutem Gewissen davon ausgehen, daß wenn abgeschnitten wird, dies am Ende passiert.

das ist natürlich wieder so einfach, daß ich da nie drauf gekommen wäre ;)

Es sollte weiterhin darauf geachtet werden, daß jede Beitragsnummer mit einem Trennzeichen abgeschlossen wird. [...]man keinerlei Möglichkeit festzustellen, ob die letzte Nummer vollständig

stimmt! Ein Trennzeichen hab ich natürlich sowieso - was will man schon mit 1259542792182264238145368413238321385321224... anfangen? Ich hab bisher nur keins am Ende - kommt jetzt aber ;)

[...]Der Bereich lässt sich effektiver nutzen, wenn man statt einfachem Dezimaltext (mit den Zeichen 0 bis 9) die Basis erweitert und das komplette Alphabet hinzunimmt. [...] (Ziffern 0-9 plus 26 Buchstaben in groß und klein) erweitern und spart noch ein wenig Platz.

ja, das ist gut - erinnert mich an meine fürchterliche Klausur die sich nur mit dem handschriftlichen Umrechen zwischen dezimal, dual und hexa-Zahlen befasste - mal wieder rauskramen ;)

vielen Dank und Gruß, Andreas
--
http://forum.andeas-lindig.de

[Sönke Tesch]

Es sollte weiterhin darauf geachtet werden, daß jede Beitragsnummer mit einem Trennzeichen abgeschlossen wird. [...]man keinerlei Möglichkeit festzustellen, ob die letzte Nummer vollständig
stimmt! Ein Trennzeichen hab ich natürlich sowieso - was will man schon mit 1259542792182264238145368413238321385321224... anfangen? Ich hab bisher nur keins am Ende - kommt jetzt aber ;)

Du solltest auch noch eines am Anfang verlangen: Dann bist Du gegen unerwartetes Geschnippel hinten und vorne geschützt und 100%ig sicher.

Gruß,
  soenk.e

PS: Ich geb' mal ungefragt meine Vorschläge zu http://extra.andeas-lindig.de/was_das/ ab, weil mir die Idee so gut gefällt:
1. Das "Administrieren"-Feld solltest Du rausnehmen und durch ein Lesezeichen in Deinem Browser ersetzen.
2. Die DOCTYPE-Zeile gehört eigentlich gaaaaanz an den Anfang einer Datei (und welche Pfade Du ersetzt, interessiert eh niemanden).
3. Die Einträge solltest Du im Quellcode (!) mit Zeilenumbrüchen (\n) versehen.
4. Es ist sehr, sehr schade, daß Du statt einer HTML-Liste <p>-Blöcke und das Windows-eigene Zeichen 149 verwendest und die <p>s auch noch für jede einzelne Zeile verballerst - so ein Bockmist (ehrlich) muß wirklich nicht sein. Warum nimmst Du nicht <li> für die Einträge und <q> für die Zitate darin?
5. Vielleicht möchtest Du extra.andeas-lindig.de etwas besser absichern?