Squid hat mich wieder geärgert. Wieder einmal. Ich hatte das Erlebnis, dass Squid Server pingt, obwohl es das nicht tun sollte. Ok, ärgerlich, aber man kann damit leben (obwohl es von Zeit zu Zeit Timeouts verursacht).
Ich kann damit leben, dass Squid Anfragen zwei- oder mehrmals sendet, obwohl es wirklich keinen Grund dafür gibt - es scheint, als ob die interne GET-Verarbeitung durcheinander kommt, wenn auf der Browser-Seite ein Timeout auftritt.
Aber was mich wirklich auf die Palme gebracht hat, war die dumme HEAD-Handhabung. Es cached HEAD-Anfragen. Ja, dumme Idee, sie wurden ursprünglich für bandbreiten sparende Anfragen erfunden. Sie sollen rausgehen und den Server überprüfen und nicht gecached werden, weil wenn das Dokument sich nicht geändert hat, der Client es nicht abrufen muss, aber es muss wissen, ob es sich geändert hat.
Ok, richte eine ACL-Regel für HEAD-Methoden ein und setze sie auf no_cache (eigentlich, was für ein hirnloser Idiot hat die "no cache deny ACL"-Syntax mit ACLs erfunden, die Seiten beschreiben, die tatsächlich nicht gecached werden sollen? Das ist zweimal rückwärts!). Sollte funktionieren. Funktioniert nicht. Wenn es vorher eine GET- oder POST-Anfrage gab, liefert ein HEAD Daten aus dem Cache, obwohl es auf no_cache gesetzt wurde. Dumm. Schlecht. Hässlich.
Also musste ich eine zusätzliche Regel einführen, um nur die GET-Anfragen zu unterdrücken, die zu schlechten HEAD-Anfragen führen könnten (glücklicherweise war dies möglich, weil ich Probleme mit AmphetaDesk und seinen Updates hatte und AmphetaDesk den Browsernamen ausfüllt). Also cache ich jetzt keine HEAD-Anfragen und keine Ergebnisse für AmphetaDesk. Funktioniert es? Nicht wirklich, wenn es noch Dokumente im Cache von Squid gibt, liefert es HEAD von diesen Dokumenten, unabhängig von der Konfiguration. Verdammt.
Also musste ich sie entfernen. Dafür ist doch die PURGE-Methode da, oder? Falsch. PURGE löscht nur Dokumente, nicht gecachte Header. Also muss man zuerst das Dokument abrufen, dann es löschen, um seine gecachten HEAD-Anfragen zu entfernen. Oh-mein-Gott.
Und jetzt habe ich immer noch einige TCP MEM HIT im Log, obwohl es nicht cachen sollte. Es scheint, als ob es das Memory-Caching anders als das Disc-Caching handelt. Oh, und dies ist reproduzierbar mit 2.2 und 2.4. Verdammt. Mistkerl.
Könnte das Leben nicht eigentlich einfacher für Sysadmins gemacht werden? Bitte?