Sönke Tesch: wo werden zu lange Cookies abgeschnitten?

Beitrag lesen

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