Auf einem Webhosting wird anscheinend ein falsches PATH_TRANSLATED ausgegeben.


PATH_TRANSLATED muss doch /kunden/homepages/3/d9/htdocs/test/index.html/ui
anstatt  /kunden/homepages/3/d9/htdocs/cgi-bin/test/index.html/ui  lauten

PATH_TRANSLATED = DOCUMENT_ROOT + PATH_INFO  ???

/EDIT: Lokal auf Apache läuft es. Auf dem Server nicht mehr, trotz gleicher Apache-Version.\n\n

<!--EDIT|GwenDragon|1139592153-->

Nachtrag: Das Problem betrifft CGI + Webhosting bei 1&1.


Habe mal gegooglet.
Das sieht mir irgendwie danach aus, als ob CGIWrap PATH_TRANSLATED zerstückelt.

Mal sehen, was der Support rausbekommt.

PS: Wehe eineR verläßt sich auf die Definitionen des CGI-Standards.

aber interessant, anscheinend funktioniert bei denen mittlerweile PATH_INFO.
nach esskars aussage hat das mal nicht funktioniert (war leer)\n\n

<!--EDIT|pq|1139593743-->

Das Problem kenne ich gut. Insbesondere von 1&1. Die haben auch mal scherzhafterweise die Document_Root von einigen Webhostingpaketen geändert ohne ihre Kunden darüber zu informieren. Das macht Spaß, vor allem bei RewriteRules die sich auf die (von Hand eingetragene) Document_Root beziehen. Ich habe ewig gebraucht um rauszufinden warum die Content Managent Systeme meiner Kunden nicht mehr liefen. Die hatte einfach nur den Pfad verlängert in dem sie "/home" vor die bestehende Document Root gesetzt haben.

Deshalb versuche ich bei CGIs immer ausgehend von $ENV{'DOCUMENT_ROOT'} oder $ENV{'SCRIPT_FILENAME'} alle Pfade selbst im Skript zusammenzusetzen. Das ist oft zuverlässiger weil Änderungen an der Verzeichnisstruktur automatisch übernommen werden. Außerdem sind die beiden Keys in den meißten Fällen vorhanden und auch richtig.

Als Beispiel
\n\n

<!--EDIT|cbxk1xg|1139594974-->

@pq
Na, PATH_INFO braucht eine ja.
Sonst kannst du keine Action-Handler schreiben.


Ich finde es ärgerlich.
Da wird zuhause entwickelt. Auch schön alte Pakete benutzt, damit alles gleich ist. Und es geht - zuhause.
Und dann will der Server draußen nicht.

Aber es gibt schlimmeres. Manche setzen PATH_INFO auf SCRIPT_URL. PATH_TRANSLATED auf SCRIPT_FILENAME.
Dann wird es lustig.

Wahrscheinlich darf ich doch den Pfad wieder per Perl zwecks Prüfung etc. auseinander- und zusammenkonstruieren.\n\n

<!--EDIT|GwenDragon|1139597155-->

Der 1&1-Support sagt dazu folgendes:

Quote

Sehr geehrte Frau ...,

Es wird der Absolute Pfad zum Skript plus den path_info ausgegeben.

Für weitere Rückfragen stehen wir Ihnen gerne zur Verfügung.

http://de.selfhtml.org/servercgi/cgi/umgebungsvariablen.htm

SelftHTML sagt zu PATH_TRANSLATED:

Quote

PATH_TRANSLATED
Enthält wie PATH_INFO den Anteil des URI nach dem Scriptnamen bis zum ersten ?, jedoch mit dem Unterschied, dass nicht der Anteil selbst aus dem URI zurückgegeben wird, sondern der vom Webserver übersetzte Datenpfad dieses Anteils. Angenommen, das Script hat die Adresse http://meine.seite.net/cgi-bin/test.pl, wurde aber mit http://meine.seite.net/cgi-bin/test.pl/querys/musicbase.sql aufgerufen. Dann könnte der zusätzliche Adressanteil /querys/musicbase.sql aus Sicht des Webservers beispielsweise in einen physischen Pfadnamen wie /usr/web/seite/querys/musicbase.sql aufgelöst werden. Diesen Pfadnamen würde PATH_TRANSLATED zurückgeben.

Quelle: http://de.selfhtml.org/servercgi/cgi/umgebungsvariablen.htm

Quote

Absolute Pfad zum Skript plus den path_info

<IRONIE>Kuck an, das hätt ich ja NIE rausbekommen.</IRONIE>

Was ist das bloss für ein Unsinn. Absoluter Pfad zum Skript + Pathinfo :angry:
Da kann eineR ja nichts mit PATH_TRANSLATED anfangen.

Merke: CGI-Variablen sind schön und net - wenn sie richtig wären.

Also selbst zusammen basteln.

Nerver trust a running system!\n\n

<!--EDIT|GwenDragon|1139901090-->