Blogix

Statische Dateien (z.B. CSS, JS, Bilder) verfügen in der Standardkonfiguration von diversen Webservern über keine Expires-Header. Dies führt dazu, dass Dateien i.d.R. vom Browser nicht im Cache zwischengespeichert werden und stets eine Anfrage an den Server gesendet wird. Neben einer größeren Belastung für den Server führt es außerdem zu langsameren Ladezeiten der Webseite. Mit dem Apache-Modul mod_exprires – bei Debian z.B. standardmäßig mit Apache installiert – kann der Expries-Header gesetzt und dem Browser mitgeteilt werden, wie lange sich dieses Element nicht ändern wird. Hierfür fügt man der .htaccess-Datei folgende Zeilen hinzu:

<IfModule mod_expires.c>
	ExpiresActive On
	#ExpiresDefault "access plus 7 days"
	ExpiresByType image/bmp "access plus 7 days"
	ExpiresByType image/gif "access plus 7 days"
	ExpiresByType image/jpeg "access plus 7 days"
	ExpiresByType image/jpg "access plus 7 days"
	ExpiresByType image/png "access plus 7 days"
	ExpiresByType image/x-icon "access plus 7 days"
	ExpiresByType text/css "access plus 7 days"
	ExpiresByType text/javascript "access plus 7 days"
	ExpiresByType text/x-js "access plus 7 days"
	ExpiresByType application/javascript "access plus 7 days"
	ExpiresByType application/x-javascript "access plus 7 days"
</IfModule>

Die Verwendung von ExpiresDefault (hier nicht aktiviert) würde dazu führen, dass für jede ausgelieferte Datei ein Expires-Header gesetzt werden würde. Dies sollte bei dynamisch generierten Webseiten vermieden, da diese aus dem Browser-Cache und nicht vom Server geladen werden und somit nicht den aktuellen Stand widerspiegeln würden. Header für JPG-Bilder und JavaScript werden in diesem Beispiel mehrfach gesetzt, damit unterschiedliche Mime-Types aufgrund verschiedener Konfigurationen von Servern und Ausgaben von Skripts abgedeckt sind.

PHP-Caches sind nicht immer nur für massive Performance-Gewinne, sondern manchmal auch für unerklärliche Fehler verantwortlich. So vertragen sich z.B. Horde und eAccelerator nicht. Die generierte Fehlermeldung lässt andere Fehlerquellen vermuten, an eAccelerator denkt man dabei aber vorerst nicht:

Warning: IMAP_Tree::require_once() [function.IMAP-Tree-require-once]: open_basedir restriction in effect. File(Horde/SessionObjects.php) is not within the allowed path(s): (/usr/share/php:/usr/share/pear:/usr/share/horde3:/etc/horde:/usr/lib:/usr/sbin:/var/log) in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Fatal error: Can’t load Horde/SessionObjects.php, open_basedir restriction. in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Man erhält also eine “open_basedir restriction”-Fehlermeldung, wie man sie schon häufig gesehen hat. Erste Vermutung ist natürlich, dass die in der php.ini konfigurierten Pfade für open_basedir nicht korrekt sind. Also sucht man zuerst nach der Datei “Horde/SessionObjects.php” und erkennt, dass sich diese an “/usr/share/horde3/lib/Horde/SessionObjects.php” befindet – dieser Pfad ist lt. open_basedir-Einstellung “…:/usr/share/horde3:…” aber eindeutig erlaubt. Die Suche geht weiter und weiter und… bis man auf die Idee kommt, dass man vor ein paar Tagen einen PHP-Cache installiert hat. Sofort nach der Deaktivierung desselbigen funktioniert wieder alles problemlos. Wie meine weiteren Recherchen herausgestellt haben, tritt dieses Problem nicht nur mit eAccelerator auf, sondern auch mit APC, usw.

Endlich ein SEO-Wettbewerb aus Österreich, nämlich von A1 unter dem Namen “SEO Rallye”. Sieger wird, wer am 18.12.2009 um 10 Uhr auf Google.at mit den Keywords “A1 Weihnachtsgeschenke” am besten rankt. Voraussetzung ist eine Verlinkung auf www.A1.net/weihnachtsgeschenke, außerdem muss man per E-Mail seine Teilnahme bestätigen. Die Teilnahmebedingungen können auf http://www.a1.net/privat/seorallye nachgelesen werden.

Da alle Teilnehmer auf die Seite www.A1.net/weihnachtsgeschenke verlinken müssen, bekommt A1 viele Links von Seiten auf denen das Keyword “Weihnachtsgeschenke” vorkommt. Das wiederum führt dazu, dass A1 eine Top-Platzierung für diesen doch sehr wertvollen Suchbegriff bekommt. D.h. A1 erkauft sich relativ günstig – nämlich mit jeweils einem Nokia Booklet, einem HTC Magic und einem Sony Ericsson W715 (Einkaufskosten dürften bei unter € 1000 liegen) – und mit wenig Aufwand (nach dem andere arbeiten lassen-Prinzip) eine Spitzenplatzierung. An Effektivität kaum zu steigern.

Probleme mit Zeichensätzen im Zusammenhang mit MySQL aber auch mit Dateien sind wohl das häufigste Problem, das einem bei der Webentwicklung begegnet. Bei MySQL wird die Datenbank häufig als UTF-8 exportiert, beim Import auf die Angabe des Datensatzes vergessen und somit häufig mit ISO-8859-1 importiert. Das führt dazu, dass auf der Webseite anstelle der Umlaute überall “?” angezeigt werden. Achtet man beim Import gleich darauf den Zeichensatz anzugeben, erspart man sich häufig einen zweiten Import bzw. eine Fehlersuche.

Der Parameter “–default-character-set=utf8″ beim Import auf der Konsole ist dabei entscheidend:

mysql -u root -p --default-character-set=utf8 database < database.sql

Sehr erfreut war ich über den Newsletter von Debian, den ich heute in meinem Postfach vorgefunden habe. Ab sofort wird jeweils im Dezember eines ungeraden Jahres der aktuelle Stand für einen neuen Release eingefroren. Im folgenden Frühjahr sollte dann mit der Veröffentlichung zu rechnen sein. D.h. dass im Schnitt alle zwei Jahre mit einer neuen stabilen Version zu rechnen ist. Das wird schlussendlich dazu führen, dass stets relativ neue Pakete in den jeweiligen stabilen Releases zu finden sein werden. Ich hoffe nur bzw. bin auch relativ überzeugt davon, dass die Stablität und Qualität nicht darunter zu leiden hat.