huschi.net

Problemstellung:

Beim Umzug von einem Server auf den nächsten stößt man immer wieder mal auf Probleme:

• Andere PHP-Version
• Andere MySQL-Version
• Fehlende Libraries (für PHP, PEAR, Perl, Python, Ruby, etc.)
• Hardcodierte Verzeichnisse
• Hardcodierte URLs
• Umstellung von Latin1/ISO-8859-1 auf UTF8
• ...

Lösungsansätze:

Um vorher in Ruhe auszutesten, ob alles funktioniert bevor man den DNS-Eintrag ändert, gibt es verschiedene Methoden:

1. Auf dem neuen Server wird für das Web ein Domain-Alias angelegt. Z.B. umzug.domain.tld und der DNS-Eintrag entsprechend erweitert.
   Damit ist das neue Web dann erreichbar und kann getestet werden. Scheitert aber z.B. bei hardcodierten URLs.
2. Zum Testen wird der DNS-Eintrag in der hosts hardcodiert. (Unter Windows in der Datei c:\Windows\system32\drivers\etc\hosts.)
   Damit laufen dann aber Systemweit alle Versuche auf die Domain zuzugreifen auf den neuen Server.
   Problematisch sobald man mal auf das alte Web nachsehen will um einen optischen 1:1-Vergleich zu machen.
   Noch schlimmer wenn über diese Domain der eigene Email-Verkehr laufen soll, der noch auf dem alten Server ist.
3. Wir nutzen eine automatische Proxy-Konfiguration (PAC). Damit kann man exakt einen (beliebigen) Browser mit der selben URL auf den neuen Server umbiegen.
   Alle oben aufgezählten Nebenwirkungen entstehen erst gar nicht.
   Einziger Nachteil: Es funktioniert nicht, wenn man bereits einen Proxy braucht um ins Internet zu gelangen.

Automatische Proxy-Konfiguration:

Die Theorie dahinter:

Eine PAC-Datei enthält ein kleine Javascript-Funktion, welche einen Proxy passend zu der Domain zurück liefert.
Da man jedem Browser eigenständig diese PAC-Datei zuspielen kann, sind die anderen Programme des Rechners nicht betroffen. D.h. man kann z.B. mit dem Firefox mit der selben Domain auf dem neuen Server arbeiten wärend im IE noch der alte Server antwortet.

Die PAC-Datei:

Im folgendem Beispiel nehmen wir uns die fiktiven IP's 111.111.111.111 für den alten Server und 222.222.222.222 für den neuen Server.
Daraus bauen wir uns eine Datei namens umzug.pac. Hier erstmal ein allgemeines Beispiel:

function FindProxyForURL(url, host) {
	var ret = 'DIRECT';
	if (url.substring(0,5)=="http:") {
		if (isInNet(host, '111.111.111.111', '255.255.255.255')) {
			ret = 'PROXY 222.222.222.222:80';
		}
	}
	return ret;
}

Diese Proxy-PAC erstmal ob es eine normale HTTP-Anfrage ist. Dies ist wichtig, da sonst evtl. der Port nicht korrekt gesetzt wird.
Im nächsten Schritt prüft es ob der angefragte Host (also die Domain) eine Auflösung auf den alten Server (die IP 111.111.111.111) hat. Dabei wird der reguläre Nameserver angefragt.
Kommt als Antwort true wird ein "PROXY [neue IP]:80" zurück geliefert.
In allen anderen Fällen ist es der Fallback DIRECT, welches soviel wie "kontaktiere ohne Proxy" heißt.

Zusammenfassung:
Die PAC-Funktion liefert also für alle HTTP-Domain-Anfragen die auf den alten Server zeigen würden die IP des neuen Servers zurück.

Aber ist unser neuer Server ein Proxy?
Nein, eigentlich nicht. Muss er auch nicht. Dem Browser ist egal ob er einen Proxy oder einen Webserver kontaktiert. Der Request ist in beiden Fällen identisch.
Daher kann auch direkt der Webserver angesprochen werden ohne dass wir auf dem neuen Server einen Proxy installieren müssen.

Konfiguration des Browsers:

Diese PAC-Datei muss über eine URL erreichbar sein.
Wichtig: Sie muss auch nach der Auflösung durch die PAC-Datei selbst weiterhin erreichbar sein!
Passende URLs auf einem lokalem Rechner wären z.B. file://C:/umzug.pac
oder wenn man einen lokalen Webserver hat: http://localhost/umzug.pac.
Eine andere Möglichkeit wäre der neue Server: http://222.222.222.222/umzug.pac.
Oder mit einer eindeutigen Domain: http://server2.DOMAIN.TLD/umzug.pac.

Der Vorteil für eine externe Proxy-PAC ist, es können auch andere Developer/Reseller/Webmaster ihren umgezogenen Webauftritt testen bevor sie das OK für den entgültigen Umzug geben.

Diese URL wird nun dem Browser mitgeteilt:
Bei Firefox und seinen Abkömmlingen befindet es sich unter:
   Extras->Einstellungen->Erweitert->Netzwerk->Verbindung->Einstellungen
Beim Microsoft Internet Explorer klickt man auf:
   Extras->Internetoptionen->Verbindungen->LAN-Einstellungen->Einstellungen
In beiden Dialogen ist das Feld gut beschriftet. Einfach aktivieren und die URL Eintragen.

Spielereien

Das o.g. Beispiel für die Proxy-PAC ist recht simpel gehalten. Man kann es präzisieren oder erweitern. Der Phantasie sind keine Grenzen gesetzt:

• Wir wollen nur eine Domain weiterleiten:

  if (dnsDomainIs(host, '.DOMAIN.TLD') ret = 'PROXY 222.222.222.222:80';

• Auch die HTTPS-Anfragen sollen weitergeleitet werden:

  if (url.substring(0,5)=="http:") {
  		if (isInNet(host, '111.111.111.111', '255.255.255.255')) {
  			ret = 'PROXY 222.222.222.222:80';
  		}
  	} else if (url.substring(0,6)=="https:") {
  		if (isInNet(host, '111.111.111.111', '255.255.255.255')) {
  			ret = 'PROXY 222.222.222.222:443';
  		}
  	}

• ...

Probleme:

Der Microsoft Internet Explorer hält die Ergebnisse in einem (APR-)Cache vor. Daher wird die Proxy-PAC nicht bei jedem Request durchlaufen. Dies kann zu seltsamen Erscheinungen führen.
Eine Anleitung, wie man den APR-Cache deaktiviert liefert Microsoft selbst: kb271361.

Beim Zugriff über einen Webserver auf die PAC-Datei kann es dazu kommen das der Browser die Datei zwar ließt, aber nicht umsetzt. Das liegt dann daran, dass ein falscher MIME-Type (meisten text/plain) im Response steht.
In diesem Fall braucht mal dem ausliefernden Webserver (z.B. Apache) lediglich den richtigen MIME-Type für PAC-Files bekannt machen:

AddType application/x-ns-proxy-autoconfig .pac

Alternativ in der mime.types:

application/x-ns-proxy-autoconfig pac

Links:

• Wikipedia: Proxy Auto-Config
• Google: Google's Pactester
• ReturnProxy.com: The Practical Proxy PAC file guide
• Microsoft: Deaktivieren der automatischen Proxyzwischenspeicherung in Internet Explorer