nicht angemeldet
Caching
Halihallo Forumer
so, hab mich jetzt durch fast das ganze Forumsarchiv 2002 durchgelesen (mit einer kleinen Themenbeschränkung auf Caching ;-))
Also: Es geht um das "anscheinend vielbesprochene" Thema: Page _nicht_ cachen. Kleiner Ansatz: es hat nix mit der "Back-Taste" des Browsers zu tun ;-)
Es geht darum einen img-Tag zu erstellen um statistische Daten zu gewinnen. Da soll natürlich das caching unterdrückt werden. Kontrollieren kann man das über die bekannten Header-Daten "Cache-Control", "no-cache" & Co.
Da ich jedoch kein Optimist bin, was das einhalten von Standards angeht, möchte ich lieber nochmals euch, Spezialisten, fragen, als mich auf eine angeblich "caching-freie" - Statistik zu verlassen.
Wird das von den "gängigen" (0815-User => IE/NS ;)) Browser'n vollständig unterstützt? - Gibt's Einschränkungen? - Gibt es Browser, die das gar nicht unterstützen?
Eine Möglichkeit würde sich bieten, <noscript> zu verwenden um einen potentiellen Fall-back als normales img auszugeben (wie oben beschrieben) und andernfalls den img-Tag durch das Script dynamisch mit rand()-Zahl auszugeben. Diese Technik ist mir bekannt und wird auch verwendet, jedoch möchte ich dennoch _nur_ etwas über das Caching-Verhalten von Browsern wissen.
Wichtige wäre hierbei auch noch zu sagen, dass das Script unter /cgi-bin läuft und somit von den meisten Browsern als weniger cachebar interpretiert wird.
Viele Grüsse
Philipp
-
Moin Moin !
telnet webserver 80
Trying 10.1.128.167...
Connected to webserver.
Escape character is '^]'.
GET /cgi-bin/mycgi.pl HTTP/1.0HTTP/1.1 200 OK
Date: Tue, 03 Sep 2002 17:50:11 GMT
Server: Apache/1.3.22 (Win32)
Expires: Mon, 02 Sep 2002 17:50:15 GMT
Pragma: nocache
Connection: close
Content-Type: text/html<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
[...]Oder in Perl:
use CGI qw(header);
print header({-expires=>'-1d',-pragma=>'nocache'});Das funktioniert hervorragend mit den verschiedensten Browsern (getestet mit IE ab 4, NN ab 4.0x, Opera ab 3.x, Mozilla).
Wie es geht: Erstmal sag ich mit pragma=>nocache, das der Browser diesen Request besser nicht in den Cache packt. Dann sorge ich mit expires=>-1d noch dafür, daß die Seite vor 24 Stunden veraltet ist. "Cache-Control: no-cache" oder so könnte man auch noch einbauen.
Ansonsten müßtest Du deine HTML-Seiten dynamisch auf dem Server erzeugen, und dafür sorgen, daß in dem IMG-Tag immer ein Teil der URL veränderlich ist. Das kann der Browser dann nicht mehr cachen.
Mit SSI (und Apache) müßte das ungefähr so gehen:
<!--#config timefmt="%s" --><!-- Sekunden seit der Epoche -->
<IMG SRC="/cgi-bin/statistik.cgi/<!--#echo encoding="url" var="DATE_GMT" -->/<!--#echo encoding="url" var="REMOTE_ADDR" -->" ALT="Just a counter">Das CGI bekommt als PATH_INFO die Aufrufzeit der SSI-Seite und die Remote IP-Adresse, getrennt durch Slashes. Die Aufrufzeit ist nützlich, um die Ladezeiten abzuschätzen, die IP-Adresse zum Verfolgen der User. Eine Zufallszahl wäre noch ganz nett, aber dafür braucht man bei SSI externe Prozesse, die in der Performance recht teuer sind. Ansatz: <!--#exec cmd="/usr/local/bin/perl -e 'print rand'" --> oder <!--#include virtual="/cgi-bin/internal/random" -->
Alexander
-
Halihallo Alexander
Das funktioniert hervorragend mit den verschiedensten Browsern (getestet mit IE ab 4, NN ab 4.0x, Opera ab 3.x, Mozilla).
Das klingt ja schon mal gut. Nur würde mich interessieren, welche Browser sich eben _nicht_ an die Spielregeln halten.
Wie es geht: Erstmal sag ich mit pragma=>nocache, das der Browser diesen Request besser nicht in den Cache packt. Dann sorge ich mit expires=>-1d noch dafür, daß die Seite vor 24 Stunden veraltet ist. "Cache-Control: no-cache" oder so könnte man auch noch einbauen.
Jep.
Ansonsten müßtest Du deine HTML-Seiten dynamisch auf dem Server erzeugen, und dafür sorgen, daß in dem IMG-Tag immer ein Teil der URL veränderlich ist. Das kann der Browser dann nicht mehr cachen.
Mit SSI (und Apache) müßte das ungefähr so gehen:
<!--#config timefmt="%s" --><!-- Sekunden seit der Epoche -->
<IMG SRC="/cgi-bin/statistik.cgi/<!--#echo encoding="url" var="DATE_GMT" -->/<!--#echo encoding="url" var="REMOTE_ADDR" -->" ALT="Just a counter">Jep. Das war auch mein Vorschlag mit dem JS-Script, was eine Zufallszahl an die URL angängt (kommt IMO aufs selbe raus). Jedoch kann ich dass nicht über SSI oder Serverscripts lösen, da ich die Pages nicht hoste. Deshalb die Lösung über den Client => JS.
Aber danke für die SSI-Comms, die kannte ich noch gar nicht (hab mich ehrlichgesagt auch noch nicht viel damit beschäftigt).Das CGI bekommt als PATH_INFO die Aufrufzeit der SSI-Seite und die Remote IP-Adresse, getrennt durch Slashes. Die Aufrufzeit ist nützlich, um die Ladezeiten abzuschätzen, die IP-Adresse zum Verfolgen der User. Eine Zufallszahl wäre noch ganz nett, aber dafür braucht man bei SSI externe Prozesse, die in der Performance recht teuer sind. Ansatz: <!--#exec cmd="/usr/local/bin/perl -e 'print rand'" --> oder <!--#include virtual="/cgi-bin/internal/random" -->
Wie willst du denn die Ladezeiten abschätzen? - Etwa die Differenz der Zeiten vom ersten bis zum letzten Hit auf die Domain mit gleicher IP? - Au waya, das würde aber bitter ins Auge gehen. Schliesslich können 1'000 Rechner dieselbe IP haben... Und eventuell lagern die Objekte auch nicht auf der selben Domain (was zwar unwahrscheinlich ist). Hinzukommt, dass der selbe User ja zwei Browserfenster gleichzeitig mit der selben Page offen hat => das führt zu Verfälschungen. Desweiteren müsstest du eine Art Zeitfenster willkührlich festlegen, wann _ein_ Zugriff spätestens fertig sein muss, da du sonst (eventuell) die Differenz zweier Requests zählst...
IP zum Verfolgen der User? - Naja, damit kann ich mich noch anfreunden. Kommt etwa auf das selbe Chaos hinaus, als wenn ich Cookies verwenden würde, leider ;)
Viele Grüsse und Danke
Philipp
-
Hi Philipp,
Das klingt ja schon mal gut. Nur würde mich
interessieren, welche Browser sich eben _nicht_
an die Spielregeln halten.keiner. Ein Browser, der realtime-Daten cachen würde,
wäre für viele kommerzielle Anwendungen untauglich.
So viel HTTP müssen die Browser alle können.Wie es geht: Erstmal sag ich mit pragma=>nocache,
das der Browser diesen Request besser nicht in
den Cache packt. Dann sorge ich mit expires=>-1d
noch dafür, daß die Seite vor 24 Stunden veraltet
ist. "Cache-Control: no-cache" oder so könnte man
auch noch einbauen.
Jep."Cache-Control" ist HTTP/1.1, die beiden anderen Header
sind HTTP/1.0. Wobei laut RFC2616 ein HTTP/1.1-fähiger
Browser im Falle widersprüchlicher Daten vorrangig die
HTTP/1.1-Aussage berücksichtigen soll (oder sogar muß -
habe ich gerade nicht im Kopf).
Du darfst also alles schicken, was Dir helfen kann.Ansonsten müßtest Du deine HTML-Seiten dynamisch
auf dem Server erzeugen, und dafür sorgen, daß in
dem IMG-Tag immer ein Teil der URL veränderlich
ist. Das kann der Browser dann nicht mehr cachen.Das ist auch eine Möglichkeit.
Jedoch kann ich dass nicht über SSI oder
Serverscripts lösen, da ich die Pages nicht hoste.
Deshalb die Lösung über den Client => JS.Was man aber abschalten kann, wodurch Deine Zahlen
prima verfälscht werden können. Mach's lieber richtig.Aber danke für die SSI-Comms, die kannte ich noch
gar nicht (hab mich ehrlichgesagt auch noch nicht
viel damit beschäftigt).SSI ist in Fällen, wo Du nur Environment-Variablen
und einfache Verzweigungen brauchst, eine ressourcen-
schonende Alternative zu CGI und PHP.Das CGI bekommt als PATH_INFO die Aufrufzeit
der SSI-Seite und die Remote IP-Adresse,
getrennt durch Slashes. Die Aufrufzeit ist
nützlich, um die Ladezeiten abzuschätzen,
die IP-Adresse zum Verfolgen der User.Sehr gewagt. Es gibt viele Möglichkeiten dafür, daß
die IP-Adresse völlig wertlos ist - Firewalls mit NAT
beispielsweise.Eine Zufallszahl wäre noch ganz nett
Als Tiebreaker ist das nicht gut geeignet. Der Server
könnte eine zuverlässige eindeutige Kennung berechnen,
beispielsweise mit der Kombination aus Uhrzeit und
Prozeß-ID.Schliesslich können 1'000 Rechner dieselbe IP
haben...Eben.
IP zum Verfolgen der User? - Naja, damit kann ich
mich noch anfreunden. Kommt etwa auf das selbe
Chaos hinaus, als wenn ich Cookies verwenden würde,
leider ;)Cookies sind im Vergleich zum IP-Adresser erheblich
sinnvoller - weil Du in den Cookie etwas definitiv
Eindeutiges schreiben kannst.Viele Grüße
Michael-
Halihallo Michael
Das klingt ja schon mal gut. Nur würde mich
interessieren, welche Browser sich eben _nicht_
an die Spielregeln halten.keiner. Ein Browser, der realtime-Daten cachen würde,
wäre für viele kommerzielle Anwendungen untauglich.
So viel HTTP müssen die Browser alle können.Richtig. Danke.
"Cache-Control" ist HTTP/1.1, die beiden anderen Header
sind HTTP/1.0. Wobei laut RFC2616 ein HTTP/1.1-fähiger
Browser im Falle widersprüchlicher Daten vorrangig die
HTTP/1.1-Aussage berücksichtigen soll (oder sogar muß -
habe ich gerade nicht im Kopf).
Du darfst also alles schicken, was Dir helfen kann.Bin mir auch nicht sicher, aber ich glaube, dass in der RFC SHOULD steht...
Jedoch kann ich dass nicht über SSI oder
Serverscripts lösen, da ich die Pages nicht hoste.
Deshalb die Lösung über den Client => JS.Was man aber abschalten kann, wodurch Deine Zahlen
prima verfälscht werden können. Mach's lieber richtig.Das würde ja auch gerne, aber die Software soll so konzeptioniert sein, dass der Kunde keine Software auf seiner Website installieren muss, deshalb bin ich auf Client-basierte lösungen angewiesen.
Klar, JS lässt sich abschalten, aber dafür gibt es den <noscript> - Container, wo ich das Bild hard-gecoded als <img> einfüge und somit immer noch gute Karten habe, dass es nicht gecached wird (HTTP-Header).Eine Zufallszahl wäre noch ganz nett
Als Tiebreaker ist das nicht gut geeignet. Der Server
könnte eine zuverlässige eindeutige Kennung berechnen,
beispielsweise mit der Kombination aus Uhrzeit und
Prozeß-ID.ja, aber der Client nicht ;-)
Wenn ich auf dem Statistik-Benutzer (namentlich Hoster seiner Website) Scripte platzieren könnte/dürfte, dann wäre die Welt ja heile, aber das ist nun mal nicht Sinn der Software, die ich programmieren muss.Schliesslich können 1'000 Rechner dieselbe IP
haben...Eben.
? - Bringst du die Personen etwas durcheinander, oder wolltest du meine Aussage intensivieren? :-)
IP zum Verfolgen der User? - Naja, damit kann ich
mich noch anfreunden. Kommt etwa auf das selbe
Chaos hinaus, als wenn ich Cookies verwenden würde,
leider ;)Cookies sind im Vergleich zum IP-Adresser erheblich
sinnvoller - weil Du in den Cookie etwas definitiv
Eindeutiges schreiben kannst.Ich verwende zur "eindeutigen" Identifikation beide Techniken, vorzugsweise natürlich den Cookie. Die IP und sonstige Browserdaten werden im Falle eines Fallbacks benutzt.
Viele Grüsse
Philipp
-
-
Halihallo Alexander
Moin Moin !
Das funktioniert hervorragend mit den verschiedensten Browsern (getestet mit IE ab 4, NN ab 4.0x, Opera ab 3.x, Mozilla).
Das klingt ja schon mal gut. Nur würde mich interessieren, welche Browser sich eben _nicht_ an die Spielregeln halten.
Alle müssen. Siehe Michael Schröpls Antwort.
Ansonsten müßtest Du deine HTML-Seiten dynamisch auf dem Server erzeugen, und dafür sorgen, daß in dem IMG-Tag immer ein Teil der URL veränderlich ist. Das kann der Browser dann nicht mehr cachen.
Mit SSI (und Apache) müßte das ungefähr so gehen:
[...]
Wie willst du denn die Ladezeiten abschätzen? - Etwa die Differenz der Zeiten vom ersten bis zum letzten Hit auf die Domain mit gleicher IP?
[...]
Hab ich leider nicht so ganz sauber geschrieben, weil der Kopf mal wieder schneller als die Finger war.
Deine Seite muß (1.) dynamisch erzeugt werden und (2.) beim Erzeugen muß in eine Datenbank (nicht notwendigerweise relational, eine Text-Datei könnte reichen) genau der zufällige Teil der Bild-URL mit Timestamp als "Startmarke" geschrieben werden. Wenn dann das Bild geladen wird, schreibt das "Bild-Ausgebe-CGI" eine entsprechende "Stopmarke" in die Datenbank.
Das Bild muß möglichst weit hinten in der HTML-Datei stehen, damit es nicht schon geladen werden kann, bevor die HTML-Datei geladen ist.
Zum Auswerten sucht man nun Paare von Start- und Stopmarken aus der Datenbank und berechnet die Zeitdifferenz.Natürlich ist das Verfahren nicht 100% sicher, allein schon deswegen, weil einige böse Surfer die Bilder nicht laden.
Aber die Kombination aus Zeit (sekundengenau), Client-IP-Adresse und einer Zufallszahl sollte einen einzelnen Surfer -- für diese Messung -- ausreichend genau identifizieren. Man kann das sicher noch weiter spinnen, z.B. den HTTP_USER_AGENT noch mit aufnehmen, oder den REMOTE_PORT (in der HTML-Seite als Parameter für das Bild). Man kann natürlich auch noch versuchen, einen eindeutigen Cookie zu setzen und den auch noch mit "verwursten".
Entscheidend ist, möglichst viele Informationen zu einem möglichst eindeutigen Key zusammenzufassen.
Alexander
-
Halihallo Alexander
Das funktioniert hervorragend mit den verschiedensten Browsern (getestet mit IE ab 4, NN ab 4.0x, Opera ab 3.x, Mozilla).
Das klingt ja schon mal gut. Nur würde mich interessieren, welche Browser sich eben _nicht_ an die Spielregeln halten.
Alle müssen. Siehe Michael Schröpls Antwort.
Das ist SEHR beruhigend, wirklich. Dachte schon, dass ich hier ins Gras beissen muss und die Aufgabe nicht lösen kann ;)
Wie willst du denn die Ladezeiten abschätzen? - Etwa die Differenz der Zeiten vom ersten bis zum letzten Hit auf die Domain mit gleicher IP?
[...]Hab ich leider nicht so ganz sauber geschrieben, weil der Kopf mal wieder schneller als die Finger war.
Deshalb die Nachfrage ;)
Zudem würde mich eine Lösung interessieren (also ich hab ja auch ein paar auf Lager).Deine Seite muß (1.) dynamisch erzeugt werden und (2.) beim Erzeugen muß in eine Datenbank (nicht notwendigerweise relational, eine Text-Datei könnte reichen) genau der zufällige Teil der Bild-URL mit Timestamp als "Startmarke" geschrieben werden. Wenn dann das Bild geladen wird, schreibt das "Bild-Ausgebe-CGI" eine entsprechende "Stopmarke" in die Datenbank.
Das Bild muß möglichst weit hinten in der HTML-Datei stehen, damit es nicht schon geladen werden kann, bevor die HTML-Datei geladen ist.
Zum Auswerten sucht man nun Paare von Start- und Stopmarken aus der Datenbank und berechnet die Zeitdifferenz.Aha. Wenn man dies nun noch auf alle Ressourcen einer Page (eg. alle externen Scripts, alle Bilder, ...) ausweiten würde, dann hätte man in der Tat eine sehr genaue Referenzzeit. Aber eben, leider bin ich auf eine Client-seitige Lösung angewiesen und da wirds bekanntlich "etwas" unmöglich ;-)
Bzw. über die von mir genannte Zwischenlösung über IP und Cookie Identification, wobei auch das, wie ich bereits beschriebene habe, ziemlich in "die Hosen gehen kann"... Aber ich denke, dass deine rein serverbasierte Lösung durchaus gut ist.Natürlich ist das Verfahren nicht 100% sicher, allein schon deswegen, weil einige böse Surfer die Bilder nicht laden.
Wenn du wie gesagt, alle Ressourcen misst, dann hättest du auch dann eine, wenn auch sehr ungenügende, Referenzzeit (eg. weil der Nicht-Bildlader das laden von externen .js Dateien nicht unterbinden kann)... Aber wie ich auch schon sagte, habe ich es vorwiegend mit 0815-Usern zu tun => Cookies aktiv, JS aktiv, Bilder aktiv, Sicherheitslücken aktiv ;)
Aber die Kombination aus Zeit (sekundengenau), Client-IP-Adresse und einer Zufallszahl sollte einen einzelnen Surfer -- für diese Messung -- ausreichend genau identifizieren. Man kann das sicher noch weiter spinnen, z.B. den HTTP_USER_AGENT noch mit aufnehmen, oder den REMOTE_PORT (in der HTML-Seite als Parameter für das Bild). Man kann natürlich auch noch versuchen, einen eindeutigen Cookie zu setzen und den auch noch mit "verwursten".
Entscheidend ist, möglichst viele Informationen zu einem möglichst eindeutigen Key zusammenzufassen.
Und dann einen MD5 darüber legen und schon hat man einen durchaus zu gebrauchenden und nahezu uniquen Fingerprint des Clients, der auch nur 128bit gross ist :-)
Viele Grüsse
Philipp
-
Moin Moin!
[...]
Wie willst du denn die Ladezeiten abschätzen? - Etwa die Differenz der Zeiten vom ersten bis zum letzten Hit auf die Domain mit gleicher IP?
[...]Hab ich leider nicht so ganz sauber geschrieben, weil der Kopf mal wieder schneller als die Finger war.
Deshalb die Nachfrage ;)
Zudem würde mich eine Lösung interessieren (also ich hab ja auch ein paar auf Lager).Deine Seite muß (1.) dynamisch erzeugt werden und (2.) beim Erzeugen muß in eine Datenbank (nicht notwendigerweise relational, eine Text-Datei könnte reichen) genau der zufällige Teil der Bild-URL mit Timestamp als "Startmarke" geschrieben werden. Wenn dann das Bild geladen wird, schreibt das "Bild-Ausgebe-CGI" eine entsprechende "Stopmarke" in die Datenbank.
Das Bild muß möglichst weit hinten in der HTML-Datei stehen, damit es nicht schon geladen werden kann, bevor die HTML-Datei geladen ist.
Zum Auswerten sucht man nun Paare von Start- und Stopmarken aus der Datenbank und berechnet die Zeitdifferenz.Aha. Wenn man dies nun noch auf alle Ressourcen einer Page (eg. alle externen Scripts, alle Bilder, ...) ausweiten würde, dann hätte man in der Tat eine sehr genaue Referenzzeit. Aber eben, leider bin ich auf eine Client-seitige Lösung angewiesen und da wirds bekanntlich "etwas" unmöglich ;-)
Bzw. über die von mir genannte Zwischenlösung über IP und Cookie Identification, wobei auch das, wie ich bereits beschriebene habe, ziemlich in "die Hosen gehen kann"... Aber ich denke, dass deine rein serverbasierte Lösung durchaus gut ist.Natürlich ist das Verfahren nicht 100% sicher, allein schon deswegen, weil einige böse Surfer die Bilder nicht laden.
Wenn du wie gesagt, alle Ressourcen misst, dann hättest du auch dann eine, wenn auch sehr ungenügende, Referenzzeit (eg. weil der Nicht-Bildlader das laden von externen .js Dateien nicht unterbinden kann)...
Doch, doch: Keine Bilder, kein Javascript, keine Cookies, keine Style Sheets (Hallo Lynx!) und schon bekomme ich nur noch die HTML-Seite.
Aber wie ich auch schon sagte, habe ich es vorwiegend mit 0815-Usern zu tun => Cookies aktiv, JS aktiv, Bilder aktiv, Sicherheitslücken aktiv ;)
Na denn schieb' ihnen doch gleich eine Hand voll unsignierter ActiveX-Controls unter! ;-)
Aber die Kombination aus Zeit (sekundengenau), Client-IP-Adresse und einer Zufallszahl sollte einen einzelnen Surfer -- für diese Messung -- ausreichend genau identifizieren. Man kann das sicher noch weiter spinnen, z.B. den HTTP_USER_AGENT noch mit aufnehmen, oder den REMOTE_PORT (in der HTML-Seite als Parameter für das Bild). Man kann natürlich auch noch versuchen, einen eindeutigen Cookie zu setzen und den auch noch mit "verwursten".
Entscheidend ist, möglichst viele Informationen zu einem möglichst eindeutigen Key zusammenzufassen.
Und dann einen MD5 darüber legen und schon hat man einen durchaus zu gebrauchenden und nahezu uniquen Fingerprint des Clients, der auch nur 128bit gross ist :-)
Tja, wenn Du ohnehin mit CGI (oder ASP/PHP/JSP/...) arbeitest, kannst Du ja auch noch 'ne MD5-Summe über die (pro Client) unveränderlichen HTTP-Header machen.
Nur: Ich habe diverse Dateien (JPEGs), die identische MD5-Summen haben, trotz unterschiedlichem Inhalt. Bei manchen Daten ist das Ergebnis von MD5 wohl auf einen sehr kleinen Bereich aus den 2^128 Möglichkeiten begrenzt. Deswegen setze ich MD5 nicht mehr als ausschließliches Verfahren ein, sondern noch mindestens ein zweites Verfahren (XOR-Summe, 16bit-Summe ohne überlauf, ...).
Stellt sich also die Frage, ob man die Client-Daten wirklich mit MD5 auf 128 Bit eindampfen muß, wo 1 MByte Festplatte doch so billig ist. ;-)
Alexander
-
Halihallo Alexander
Wenn du wie gesagt, alle Ressourcen misst, dann hättest du auch dann eine, wenn auch sehr ungenügende, Referenzzeit (eg. weil der Nicht-Bildlader das laden von externen .js Dateien nicht unterbinden kann)...
Doch, doch: Keine Bilder, kein Javascript, keine Cookies, keine Style Sheets (Hallo Lynx!) und schon bekomme ich nur noch die HTML-Seite.
Ja, klar. Die wahrscheinlichkeit ist aber dennoch grösser, je mehr "Unterobjekte" man erfasst. Aber der Extremfall, wie du ihn beschrieben hast, naja, da ist dann wirklich Endefeuer ;)
Aber wie ich auch schon sagte, habe ich es vorwiegend mit 0815-Usern zu tun => Cookies aktiv, JS aktiv, Bilder aktiv, Sicherheitslücken aktiv ;)
Na denn schieb' ihnen doch gleich eine Hand voll unsignierter ActiveX-Controls unter! ;-)
Au waya... Da erschiess ich mich doch lieber gleich ;-))
Aber die Kombination aus Zeit (sekundengenau), Client-IP-Adresse und einer Zufallszahl sollte einen einzelnen Surfer -- für diese Messung -- ausreichend genau identifizieren. Man kann das sicher noch weiter spinnen, z.B. den HTTP_USER_AGENT noch mit aufnehmen, oder den REMOTE_PORT (in der HTML-Seite als Parameter für das Bild). Man kann natürlich auch noch versuchen, einen eindeutigen Cookie zu setzen und den auch noch mit "verwursten".
Entscheidend ist, möglichst viele Informationen zu einem möglichst eindeutigen Key zusammenzufassen.
Und dann einen MD5 darüber legen und schon hat man einen durchaus zu gebrauchenden und nahezu uniquen Fingerprint des Clients, der auch nur 128bit gross ist :-)
Tja, wenn Du ohnehin mit CGI (oder ASP/PHP/JSP/...) arbeitest,
^^^^^^^^^^^^^^^^^^^^^^^^^^
Pfui! CGI oder PHP, ja? :-))
kannst Du ja auch noch 'ne MD5-Summe über die (pro Client) unveränderlichen HTTP-Header machen.
Das ward ja oben beschrieben oder nicht!?
Nur: Ich habe diverse Dateien (JPEGs), die identische MD5-Summen haben, trotz unterschiedlichem Inhalt. Bei manchen Daten ist das Ergebnis von MD5 wohl auf einen sehr kleinen Bereich aus den 2^128 Möglichkeiten begrenzt. Deswegen setze ich MD5 nicht mehr als ausschließliches Verfahren ein, sondern noch mindestens ein zweites Verfahren (XOR-Summe, 16bit-Summe ohne überlauf, ...).
Gut, wenn du die Eineindeutigkeit sicher stellen musst, dann wirst du das wirklich tun müssen. Aber ich glaube, dass wir in dieser Aufgabenstellung nicht auf eine 100% sichere Eineindeutigkeit angewiesen sind. Aber naja, wenn schon, denn schon ;)
Stellt sich also die Frage, ob man die Client-Daten wirklich mit MD5 auf 128 Bit eindampfen muß, wo 1 MByte Festplatte doch so billig ist. ;-)
und wenn's finanziell mal knapp wird, kann man auf &Compress::Zlib::compress ausweichen :-)
Wobei die Ratio bei derart kleinen Incore-Strings wohl negativ wird ;-)Viele Grüsse
Philipp
-
-
-
-
-