Ich bin jetzt zweimal auf ein Problem im Zusammenhang mit Typo3 und dem Nivo-Slider gestoßen. In beiden Fällen hat ein Browser die Bilder im Slider bei jedem Durchlauf neu geladen und damit eine gewisse Netzlast erzeugt, natürlich abhängig von der Internetanbindung des zugehörigen Rechners.

In einem ersten Durchlauf habe ich die zugehörige IP mit iptables blockiert und konnte anhand der IP den Verursacher erreichen. Im zweiten Fall ist das aber ein Ntuzer mit dynamischer IP, die sich täglich ändert. Das kann auf Dauer mühsam werden da am Ball zu bleiben, zumal der Verursacher keine weiteren Informationen bekommt.

Daher habe ich jetzt versucht per .htaccess der IP-Adresse eine andere Seite mit Probleminformationen zukommen zu lassen. Dazu habe ich die .htaccess von dem zugehörigen Typo3-System um folgende Zeilen erweitert:

RewriteCond %{REMOTE_ADDR} ^192\.168\.1\.1$  
RewriteCond %{REQUEST_URI} !^\/sorry\.html
RewriteRule $ /sorry.html [R=302,L]

Die IP-Adresse habe ich hier natürlich verändert.

Jeder Aufruf von dem Rechner aus wird also auf die Seite sorry.html umgeleitet, die Hinweise auf das Problem liefert.

Quellen:
http://www.the-art-of-web.com/system/rewrite/
http://www.modrewrite.de/mod-rewrite/beispiele/ip-bereiche-blocken/

Da in meinen Webserver-Log-Dateien häufiger Anfragen nach Dateien namens wpad.dat auftauchten habe ich mich mal mit dem Thema Web Proxy Autodiscovery Protocol (WPAD) beschäftigt. Positiv daran ist, dass es als Webstandard gilt und von allen aktuellen Browsern unterstützt wird. WPAD benutzt Proxy Auto-Configuration (PAC) Dateien um die Einstellungen zu übermitteln.

Diese Dateien dienen dazu Browser automatisch zu konfigurieren, so dass sie sich die Proxy-Einstellungen selbständig erfragen können. Grundlage dafür ist eine Konfigurationsdatei namens wpad.dat, die im einfachsten Fall folgenden Inhalt besitzt:

function FindProxyForURL(url, host)
{
  if(isPlainHostName(host) || localHostOrDomainIs(host, "localhost") ||  localHostOrDomainIs(host, "127.0.0.1") || isInNet(host, "192.168.1.1", "255.255.0.0")) {
     return "DIRECT";
  }else {
     return "PROXY 192.168.1.1:3128";
  }
}

Im Prinzip wird hier in der letzten Zeile die Adresse und der Port des Proxy-Server übergeben. Der Teil davor umgeht den Proxy-Server, wenn ein Rechnername ohne Domain aufgerufen wird, der Name oder die IP für localhost oder ein Rechner aus dem lokalen Netz.

Detaillierte Informationen findet man unter http://findproxyforurl.com und natürlich http://de.wikipedia.org/wiki/WPAD.

Diese Datei muss nun nur noch zum Browser kommen. Dazu muss der Browser passend eingestellt sein: Bearbeiten -> Einstellungen -> Erweitert -> Netzwerk -> Verbindung -> Einstellungen -> Die Proxy-Einstellungen für dieses Netzwerk automatisch erkennen

Nun muss auf dem Server noch der Webserver-Apache entsprechend konfiguriert werden. Er sollte im Idealfall auf folgende URL hin die Datei ausliefern: http://wpad.<rechnername.lokale-domain>/wpad.dat In den meisten Installationen langte es sicherlich im Nameserver einen cname für wpad einzurichten:

wpad       CNAME   boss

Zusätzlich wird noch empfohlen die zugehörigen Mime-Types zu registrieren. Dazu kommen folgende Zeilen in die bisher leere Datei /etc/apache2/httpd.conf:

AddType application/x-ns-proxy-autoconfig .dat
AddType application/x-ns-proxy-autoconfig .pac
Redirect permanent  /proxy.pac /wpad.dat

Hier sind zwei Dateien eingetragen, die wpad.dat und die proxy.pac, die beide identisch sind. Eine Version ist für WPAD-fähige Systeme zuständig, die andere für ältere Versionen. Durch den Redirect muss nur eine der beiden Dateien wirklich vorhanden sein. Anfragen an die andere Datei werden passend weitergeleitet.

Im Prinzip suchen die Browser nun nach einem festen System nach der Konfigurationsdatei. Man kann ihnen das Leben erleichtern und auch den cname wpad für den Webserver vermeiden, wenn man die DHCP-Server Konfiguration etwas anpasst.

# /etc/dhcpd.conf
#
# Configuration file for ISC dhcpd
#
# -- global options --
default-lease-time                 160000;
max-lease-time                     200000;
use-host-decl-names                on;
option dhcp-max-message-size       1024;
option wpad code 252 = text;
ddns-update-style                  none;
authorative;

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.40 192.168.1.160;
    server-identifier 192.168.1.1;
    option broadcast-address 192.168.1.255;
    option routers 192.168.1.254;
    option domain-name-servers 192.168.1.1, 192.168.1.254;
    option domain-name "debacher.net";
    option wpad "http://www.debacher.net/wpad.dat ";
}

Die beiden hinzuzufügenden Zeilen sind fett unterlegt. Damit wird dem Client-Rechner schon beim Starten die Adresse der wpad.dat (Code 252) mit übermittelt. Hier ist eine beliebige URL möglich, die auch nicht unbedingt im eigenen Netz liegen muss. Die Adressübermittlung per DHCP hat übrigens Vorrang gegenüber der Übermittlung per DNS. Man muss also nicht unbedingt an den Nameserver heran.

Weitere Informationen:

Ich bin eben über einen kleinen Unterschied gestolpert. Bei einer Typo3-Installation funktionierte die cal-Extension nicht, das Backend blieb weiß. Ursache war, dass eine Programmkomponente den Include-Path erweitern wollte, was aber nicht funktionierte. Es schein so zu sein, dass der Include-Pfad nicht von PHP_programmen aus geändert werden kann, wenn in der Konfigurationsdatei der Befehl lautet:

    php_admin_value include_path "/srv/www/vhosts/meine-domain.de/httpdocs:./:/srv/www/vhosts/typo3_src-4.1.10"

Bei der Version:

    php_value include_path "/srv/www/vhosts/meine-domain.de/httpdocs:./:/srv/www/vhosts/typo3_src-4.1.10"

klappt das Erweitern des Pfades hingegen.