Scheinbar haben sich vor einiger Zeit die Dateinamen/Versionen geändert, aber es wurde versäumt die Update Seite zu kontrollieren. Während der Installation versucht Eclipse Dateien herunterzuladen die es auf dem Server nicht (mehr) gibt.

Was kann man also machen?
Die Lösung des Problems ist eigentlich recht einfach. Das einzige was wir hierzu benötigen ist ein Apache Server mit aktiven mod_rewrite, ein Packprogramm und ein Texteditor.

Speichert die content.jar der Update Seite auf eurem PC und entpackt den Inhalt in einen Ordner eurer Wahl. Es sollte jeder handelsübliche Packer, der das ZIP Format versteht, möglich sein.
In dem Zielordner sollte sich jetzt eine content.xml befinden. Öffnet diese mit einem Textprogramm und ersetzt alle Vorkommnisse von 20091116 durch 20091124. Packt die content.xml nun wieder in eine ZIP Datei und nennt diese content.jar.

Erstellt eine .htaccess und fügt folgenden Inhalt ein:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.* http://downloads.zend.com/pdt/$0 [L]

Ihr habt jetzt eine .htaccess die jede Anfrage an eine nicht existierende Datei an die offizielle Update Seite weiterreicht.
Legt beide Dateien nun in ein Verzeichnis unterhalb eures Apache Web Roots und tragt die URL als Update Seite bei eclipse ein.

Ihr könnt nun ohne größere Schwierigkeiten den Zend Debugger installieren. Wer keine Lust hat die Änderungen selbst durchzuführen, oder den Text durchzulesen, der kann sich die geänderten Dateien auch herunterladen, oder er trägt http://a2.localdev.de/zend/ als Update Seite ein.

Downloads:

• Zend PDT Update Site Fix

HTTP/1.1 417 Expectation Failed

Dies liegt daran, das die Programme einen Expect: 100-continue Header senden, und als Antwort 100 (Continue) oder 417 Expectation Failed erwarten. Lighty kennt den Header jedoch nicht, und antwortet deswegen mit dem besagten 417 Expectation Failed.

Der Expect: 100-continue Header soll verhindern, das Daten an den Server gesendet werden, die nicht benötigt werden. Erkennt der Server z.B. das er die Anfrage ablehnen muss, kann er dies dem Client mitteilen, noch bevor die POST Daten übermittelt wurden.

Wer dennoch POST Daten an Lighty senden möchte, kann die folgenden Paramter anpassen:

.NET

System.Net.ServicePointManager.Expect100Continue = false;

cURL unter PHP

curl_setopt($objCurl, CURLOPT_HTTPHEADER, array('Expect: '));

cURL auf der Kommandozeile

curl -v -H "Expect: " -F "field=value" http://example.com/upload.php

Alternativ aktualisiert man auf Lighttpd 1.5. Dieser kennt den Expect: 100-continue Header und beantwortet entsprechende Anfragen korrekt.

Browser senden übrigens keinen Expect: 100-continue Header.

Schade das, bei vielen Beschenkten, scheinbar der Firefox abstürzt oder Probleme beim Starten hat.

Dieser Auszug stammt von einem unserer Debian Server und repräsentiert in jeder Zeile einen HTTP 500 Error.

Aug 17 11:44:14 srv1 suhosin[14716]: ALERT - canary mismatch on erealloc() - heap overflow detected (attacker '80.*.*.*', file '../index.php')
Aug 17 11:44:15 srv1 suhosin[14717]: ALERT - canary mismatch on erealloc() - heap overflow detected (attacker '80.*.*.*', file '../index.php')
Aug 17 11:44:16 srv1 suhosin[14718]: ALERT - canary mismatch on erealloc() - heap overflow detected (attacker '80.*.*.*', file '../index.php')
Aug 17 11:44:16 srv1 suhosin[14719]: ALERT - canary mismatch on erealloc() - heap overflow detected (attacker '80.*.*.*', file '../index.php')

Was ist passiert?
Suhosin versucht Attacken auf Sicherheitslücken in PHP bzw. PHP Skripten zu erkennen und zu verhindern. Hierzu überwacht es u.a. den Arbeitsspeicher, und fügt beim Schreiben von Daten noch eigene Informationen hinzu. Sind diese Informationen beim Abrufen fehlerhaft, oder fehlen sie komplett, glaubt Suhosin einen Fehler zu erkennen, und beendet die Ausführung von PHP.

Wie? Wo? Was?
Ob der Kern oder ein Modul von PHP Schuld haben, lässt sich nicht so einfach sagen, da Suhosin zu wenig Informationen liefert. Man geht aber davon aus, das die Fehler in den PHP Modulen stecken.

Was kann ich machen?
Entweder man deaktiviert alle PHP Module nacheinander, bis kein Fehler mehr auftritt, oder man deaktiviert direkt Suhosin. Update: Auch mit ausgeschaltetem Suhosin kann der Fehler auftreten, da das Verhalten durch den Hardened-PHP Patch direkt im Kern steckt. Interessanterweise bringt das deaktivieren von Suhosin eine derartige Senkung mit sich, das ich nur durch eine eindeutige Fehlkonfiguration von PHP den Fehler wieder zu sehen bekam (session.save_handler war auf memcache eingestellt, memcached selber aber nicht gestartet).

Warum Kanarienvogel?
Der Kanarienvogel (canary) in der Fehlermeldung bezieht sich auf den Bergbau. Dort hat man in der Vergangenheit Kanarienvögel mit in den Untergrund genommen, um zu prüfen ob in einem Stollen genug Sauerstoff vorhanden war. Sind die Vögel verendet, wusste man das Gefahr droht, und hat die Arbeit sofort beendet.