schlimmer CGI-Fehler / CGI Error behindert Cont.-Website

[d767net]

Liebe Contenido-Community!

Ich benötige dringende Hilfe bei folgendem Fehler (hoffe, ich habe an alle wichtige Daten gedacht).
Er verhinder momentan die Arbeit an und den Onlinegang der von mir eingerichteten Contenido-Website.
Recherche im Contenido-Forum hat leider bislang weder Aufklärung noch Abhilfe gebracht.

Ich vermute es ist eher ein php/IIS-Bug als ein Contenido-Bug. Aber eben ein Contenido-spezifisches Problem, das mir ziemliches Kopfzerbrechen bereitet - deshalb zähle ich auf Eure Erfahrung und Ideen!

herzliche Grüße und vielen, vielen Dank für Eure Hilfe!

Daniel


Fehlerbeschreibung:
=======================

Unter dem CMS Contenido 4.5.3 beta kommt bei jedem x-ten Zugriff (sporadisch, aber hartnäckig) als Antwort vom Webserver nur auf weisser Seite der Fehler:

CGI-Fehler
Die angegebene CGI-Anwendung hat keinen vollständigen Satz von HTTP-Headern zurückgegeben.

Manchmal wird auch überhaupt keine Antwort zurückgeliefert, oder ein http 404 Fehler.

Das PRoblem tritt durchgehend im Dateiverwaltungs-Hauptframe auf, und immer wieder in anderen Backend-BEreichen, sporadischauch im Frontend-Bereich.
OFt hilft dann nur, einige Zeit (Minuten) zu warten und die betreffende Seite erneut aufzurufen.

Bis auf das aufgrund des Fehlers nie zugängliche Dateiverwaltungs-Hauptframe scheint dieser Fehler nicht mit einer bestimmten Seite/Script verbunden zu sein, sondern sporadisch überall aufzutreten (wie gesagt sogar im Frontend).
Im Hauptframe des Dateiverwaltungs Bereichs im Backend lässt sich dieser Fehler bei jedem Zugriff repoduzieren.


Erklärung?
=============

Folgenden Sachverhalt habe ich mit etwas www-Suche ausfindig gemacht:

>>>>
Unter IIS haben wir das Problem, das Der User mit PHP als CGI ab und zu einen CGI-Error bekommt und die entsprechende Seite neu laden muß.
...
ausserdem versagt ab und an $php_self wenn man unter Win php als CGI laufen lässt.
<<<< [http://www.it-development.de/forum/show ... eadid=8800]

Trifft die hier zu?



Server-Informationen
=======================

aus phpinfo:

PHP Version 4.3.10
System Windows NT 5.2 build 3790
Server API CGI/FastCGI
PHP API 20020918
SERVER_SOFTWARE Microsoft-IIS/6.0

MySQL
Client API ver. 3.23.49


aus Contenido "System variables" - Ausgabe:

Contenido version 4.5.3 Beta

safe_mode deactivated
magic_quotes_gpc activated
magic_quotes_runtime deactivated
gpc_order GPC
memory_limit
max_execution_time 300
Disabled functions nothing disabled
Gettext extension not loaded
sql.safe_mode deactivated


Das Feld ist rot und hat folgenden (fehlerhaften?) Inhalt:

Browser path http://

(In der Ausgabe der Contenido-"System variables"-Seite erscheint im übrigen auch ganz oben im Frame der Fehler "Warning: parse_url(http://): Unable to parse url in d:\home\web26\hera01\ftproot\www.pro-heraldica.de\cms\contenido\includes\functions.system.php on line 120" - hat das Relevanz für obigen CGI-Fehler?)


Lösungsansätze?:
================

Nach etwas weiterer Recherche, u.a. im Bug-Bereich von php.net habe ich folgende "Ideen" gefunden... ideen deshalb, weil die beschriebenen Probleme Ähnlich sind ("CGI Error") aber in Art und Weise nicht tatsächlich vergleichbar:

1.) in php.ini: [ http://bugs.php.net/bug.php?id=24916 ]


a) cgi.rfc2616_headers = 0

b) auskommentieren:

;cgi.redirect_status_env = ENV_VAR_NAME

c) ?
cgi.force_redirect = 0


2.) Problem mit php-Warnung, die das Versenden von http-headern verhindern?
-> eigentlich schon getestet (nur noch echte php-errors werden ausgegeben)...

[emergence]

Das Feld ist rot und hat folgenden (fehlerhaften?) Inhalt:

Browser path http://

(In der Ausgabe der Contenido-"System variables"-Seite erscheint im übrigen auch ganz oben im Frame der Fehler "Warning: parse_url(http://): Unable to parse url in d:\home\web26\hera01\ftproot\www.pro-heraldica.de\cms\contenido\includes\functions.system.php on line 120" - hat das Relevanz für obigen CGI-Fehler?)

ähm nein glaube ich nicht das es relevant ist...

das feld ist deshalb rot weil es ein IIS ist...
die variable($_SERVER['REQUEST_URI']) die verwendet wird, um den browser pfad anzuzeigen, steht auf einem IIS nicht zur verfügung...