Was macht dieses Stück Code?

[steveq]

  
if ( basename (getenv ('SCRIPT_NAME')) == basename (__FILE__) ) {  
 if ( !headers_sent() ) header ("Location: 404.php");  
 exit;  
}  

Ich habe ein Webprojekt übernommen und versuche mich da einzuarbeiten.
Komme auch gut klar mit den meisten Sachen, nur finde ich ab und zu bei Dateien, die eingebunden werden, obiges Codeschnipsel am Anfang.

Ich kann mir zwar die einzelnen Befehle erklären, bekomm es aber nicht auf die Reihe, was die Kombination der Befehle genau macht bzw. wozu das gut sein soll.

"übersetzt" heisst es doch "Wenn der reine Dateiname gleich dem reinen Namen der Datei ist, aber die Header (welche auch immer) noch nicht gesendet sind (warum auch immer das passieren sollte), dann rufe die 404-Seite aus".

Ich verstehe aber nicht, wieso die Dateinamen unterschiedlich sein könnten und  ich weiss auch nicht, in welchen Fällen es sein kann, dass die Header-Daten noch NICHT gesendet worden sind.

Kann mir das evtl. jmd. erklären?

Vielen Dank

[Cheatah]

Hi,

if ( !headers_sent() ) header ("Location: 404.php");

der Autor dieses Codes wusste nicht, dass beim Location-Header *unbedingt* eine *absolute* URL stehen *muss*. Du solltest diesen Fehler unbedingt schnellstmöglich beheben.

Ich kann mir zwar die einzelnen Befehle erklären, bekomm es aber nicht auf die Reihe, was die Kombination der Befehle genau macht bzw. wozu das gut sein soll.

Es verhindert, dass die der Einbindung dienende Datei direkt per HTTP aufgerufen wird.

Ich verstehe aber nicht, wieso die Dateinamen unterschiedlich sein könnten

Dann lasse Dir die Werte ausgeben und vergleiche sie bei einer Inkludierung und bei einem "direkten" Aufruf.

und  ich weiss auch nicht, in welchen Fällen es sein kann, dass die Header-Daten noch NICHT gesendet worden sind.

Vermutlich in allen, die für dieses Code-Fragment eine Rolle spielen.

Cheatah

[ChrisB]

Hi,

if ( !headers_sent() ) header ("Location: 404.php");

der Autor dieses Codes wusste nicht, dass beim Location-Header *unbedingt* eine *absolute* URL stehen *muss*. Du solltest diesen Fehler unbedingt schnellstmöglich beheben.

Darueber hinaus erzeugt er, wenn durch diese Umleitung dann die Ressource 404.php vom Browser angefordert wird, zunaechst mal wieder einen 200 OK Statuscode - und bei derartiger Ahnungslosigkeit ist vermutlich anzunehmen, dass er auch diesen Umstand dann nicht korrigiert hat. (Ich gehe auf Grund des Namens mal davon aus, dass dieses Script die File Not Found-Fehlerbehandlung uebernehmen soll.)

MfG ChrisB

[Olli]

Hallo,

if ( !headers_sent() ) header ("Location: 404.php");

der Autor dieses Codes wusste nicht, dass beim Location-Header *unbedingt* eine *absolute* URL stehen *muss*. Du solltest diesen Fehler unbedingt schnellstmöglich beheben.

Das ist mir auch neu, habe in all den Jahren auch immer nur auf eine Datei verwiesen anstatt daraus eine absolute URL zu machen. Ist wie mit vielen Dingen, klappt ja also merkt man keinen Fehler.

Aber da wäre meine Frage, wenn es denn immer geklappt hat, warum ist es dann verboten, bzw. muss ich nun wirklich(BITTE NICHT) alle Scripte meine letzten Jahre mit relativen Verweisen in dieser HEADER-Angabe ändern?

Olli

[Cheatah]

Hi,

Das ist mir auch neu,

RFC 2616 legt als Wert für den Location-Header "absoluteURI" fest.

Ist wie mit vielen Dingen, klappt ja also merkt man keinen Fehler.

Ja. Und wie mit vielen - nämlich allen - Dingen ist "klappt ja" absolut bedeutungslos. Von Bedeutung sind:

• Es klappt *nicht* (Ausschlusskriterium) und
• es ist richtig.

Aber da wäre meine Frage, wenn es denn immer geklappt hat, warum ist es dann verboten,

Es klappt wegen der Fehlerkorrekturroutinen einiger weniger Programme. Kleiner Tipp: Im IE klappt es übrigens nicht. Spätestens dann, wenn mehrere Redirects über Domaingrenzen hinweg gehen.

bzw. muss ich nun wirklich(BITTE NICHT) alle Scripte meine letzten Jahre mit relativen Verweisen in dieser HEADER-Angabe ändern?

Ich wüsste nicht, was so prickelnd daran sein soll, kritische Fehler beizubehalten.

Cheatah

[Olli]

Hi,

Es klappt wegen der Fehlerkorrekturroutinen einiger weniger Programme. Kleiner Tipp: Im IE klappt es übrigens nicht. Spätestens dann, wenn mehrere Redirects über Domaingrenzen hinweg gehen.

jetzt verstehe ich gar nichts mehr. Habe bei solchen Headerangaben nie
und auch nicht mit einer IE- Version ein Problem gehabt.

Reden wir vielleicht irgendwie von 2 verschiedenen Dingen?

Ich lege mal ein Beispiel ins Netz:
Beispiel

bzw. muss ich nun wirklich(BITTE NICHT) alle Scripte meine letzten Jahre mit relativen Verweisen in dieser HEADER-Angabe ändern?

Ich wüsste nicht, was so prickelnd daran sein soll, kritische Fehler beizubehalten.

Wenn es denn wirklich kritisch ist.

Gruss
Olli

[Cheatah]

Hi,

jetzt verstehe ich gar nichts mehr. Habe bei solchen Headerangaben nie
und auch nicht mit einer IE- Version ein Problem gehabt.

Reden wir vielleicht irgendwie von 2 verschiedenen Dingen?

nein. Dass Dir die existierenden Probleme noch nie begegnet sind, ändert nichts an der Sachlage, dass sie existieren.

Ich lege mal ein Beispiel ins Netz:
Beispiel

GET /ad6967 HTTP/1.1
Host: i80.de
=>
HTTP/1.1 302 Found
[...]
Location: http://nabuga.kilu.de/test/

GET /test/ HTTP/1.1
Host: nabuga.kilu.de
=>
HTTP/1.1 200 OK

Völlig korrekt.

Wenn es denn wirklich kritisch ist.

Etwas mit dem Argument "bisher ist noch nichts passiert" schönzureden hat sich noch nie als weise erwiesen.

Cheatah

[Olli]

Hi,

du weisst schon, dass deinen Erläuterungen nur schwer zu folgen ist?

Du sagst der IE würde auf jeden Fall ein Problem daraus machen. daher dachte ich du meinst vielleicht etwas gans anderes...

Reden wir vielleicht irgendwie von 2 verschiedenen Dingen?

nein. Dass Dir die existierenden Probleme noch nie begegnet sind, ändert nichts an der Sachlage, dass sie existieren.

... so legte ich das Beispiel ins Netz, nur um sicherzugehen, das der IE mir
dann deinen Ankündigungen gemäss, das fehlerhaft ausgibt.....

Beispiel

GET /ad6967 HTTP/1.1
Host: i80.de
=>
HTTP/1.1 302 Found
[...]
Location: http://nabuga.kilu.de/test/

GET /test/ HTTP/1.1
Host: nabuga.kilu.de
=>
HTTP/1.1 200 OK

Völlig korrekt.

... und nun schreibst du völlig korrekt, Was ist korrekt UND was macht der IE(weil er mit so einer Headerangabe angeblich nicht umgehen kann)?

Wenn es denn wirklich kritisch ist.

Etwas mit dem Argument "bisher ist noch nichts passiert" schönzureden hat sich noch nie als weise erwiesen.

Das wage ich zu bezweifeln, sowohl im Leben als auch im Programmieren.
Sonst dürfte es keine Rennfahrer oder sonstige Extremsprotler geben und
Windows wäre nicht das führende Betriebssystem.

Auch bin ich der Meinung es gibt keine absolut fehlerhaften grossen Programm, sonst gäbe es nicht BUGREPORTE.

Olli

[Cheatah]

Hi,

du weisst schon, dass deinen Erläuterungen nur schwer zu folgen ist?

ich sehe, Du hast verstanden.

Du sagst der IE würde auf jeden Fall ein Problem daraus machen.

_Auf_ jeden Fall, nicht aber _in_ jedem Fall.

... so legte ich das Beispiel ins Netz, nur um sicherzugehen, das der IE mir
dann deinen Ankündigungen gemäss, das fehlerhaft ausgibt.....

Das Beispiel liefert einen Location-Header mit absoluter URL aus, also exakt das Richtige.

Location: http://nabuga.kilu.de/test/
Völlig korrekt.
... und nun schreibst du völlig korrekt, Was ist korrekt UND was macht der IE(weil er mit so einer Headerangabe angeblich nicht umgehen kann)?

Der IE hat in bestimmten Fällen mit relativen URIs im Location-Header Probleme, also mit dem, was man _nicht_ machen darf. Dein Beispiel ist, soweit ich es sehen konnte, absolut konform zu RFC 2616, es enthält _nichts_ Problematisches. Nicht mal für den IE.

Etwas mit dem Argument "bisher ist noch nichts passiert" schönzureden hat sich noch nie als weise erwiesen.
Das wage ich zu bezweifeln, sowohl im Leben als auch im Programmieren.

Das ist sehr bedauerlich für Dich.

Sonst dürfte es keine Rennfahrer oder sonstige Extremsprotler geben und

Das Risiko professionell zu bewerten und entsprechende Sicherheitsmaßnahmen einzuleiten ist etwas völlig anderes als aus Faulheit nichts gegen ein Problem zu unternehmen.

Windows wäre nicht das führende Betriebssystem.

Und die Dummheit der Masse zu Rate zu ziehen hilft Dir auch nicht. Du bist nicht die Masse, Du bist _einer_.

Auch bin ich der Meinung es gibt keine absolut fehlerhaften grossen Programm, sonst gäbe es nicht BUGREPORTE.

Äh? Okay. Ich werde die Meinung an sich mal außen vor lassen. Aber was hat das mit dem aktuellen Problem zu tun? Du kannst weder einem (z.B.) Firefox vorwerfen, den Fehler auf (für Dich) richtige Weise zu korrigieren, noch dem IE, es nicht zu tun. Fehler sind _Fehler_. Das Verhalten eines Clients, der auf einen falschen Location-Header trifft, ist undefiniert. Er darf *alles* damit machen, inklusive der Ausgabe einer Fehlermeldung oder dem Ignorieren des kompletten Headers. Dass einige wenige Programme dies nicht tun, ist kein Generalablass für defekten Code.

Cheatah

[Olli]

Das Beispiel liefert einen Location-Header mit absoluter URL aus, also exakt das Richtige.

Location: http://nabuga.kilu.de/test/
Völlig korrekt.

Da meinst du die falsche URL:

Nimm mal diese:
http://nabuga.kilu.de/test/index.php?go=1

Und wie der Code dir eindeutig zeigt, auf CODE, ist es keine absolute URL.

Dennoch meckert kein IE.

Olli

[Cheatah]

Hi,

Da meinst du die falsche URL:

die, die Du mir nanntest.

Nimm mal diese:

Ja, da findet sich ein defekter Location-Header.

Dennoch meckert kein IE.

Erstens habe ich zu keinem Zeitpunkt behauptet, der IE würde *immer* an derlei Dingen versagen. Zweitens ist ein funktionierender Testfall kein Beweis für die Korrektheit eines Systems[1]. Kannst Du garantieren, dass dieser Redirect unter *allen* Umständen in *allen* Kontexten mit *jedem* konformen Client funktioniert?

Ich kann Dir nur das Gegenteil garantieren.

Cheatah

[1] Sondern eher ein Beleg für das Gefundenhaben eines Spezialfalls.

[Olli]

Hi,

Ja, da findet sich ein defekter Location-Header.

Dennoch meckert kein IE.

Erstens habe ich zu keinem Zeitpunkt behauptet, der IE würde *immer* an derlei Dingen versagen. Zweitens ist ein funktionierender Testfall kein Beweis für die Korrektheit eines Systems[1]. Kannst Du garantieren, dass dieser Redirect unter *allen* Umständen in *allen* Kontexten mit *jedem* konformen Client funktioniert?

Doch hast du behauptet, zitat:

Es klappt wegen der Fehlerkorrekturroutinen einiger weniger Programme. Kleiner Tipp: Im IE klappt es übrigens nicht.

Ich kann Dir nur das Gegenteil garantieren.

Das glaube ich Dir nicht, wie ich schon sagte, laufen meine Scripte seit Jahren mit diesem *Fehler, ohne dass je ein Browser versagt hätte.

Wenn du nun meinst ich sollte diese fehlerhaften Files alle aufspüren und korregieren, dann werde ich das(auch wenn das Monate dauern wird)tun. Aber nur wenn das wirklich ein Risiko birgt, wovon du mich bisher nicht wirklich überzeugen konntest. Ein kleines Beispiel würde mir reichen.

Olli

[Olli]

Wenn du nun meinst ich sollte diese fehlerhaften Files alle aufspüren und korregieren, dann werde ich das(auch wenn das Monate dauern wird)tun. Aber nur wenn das wirklich ein Risiko birgt, wovon du mich bisher nicht wirklich überzeugen konntest. Ein kleines Beispiel würde mir reichen.

Ach noch etwas, ich denke nicht das du ein Beispiel bringen kannst, weil jeder Browser auch mit relativen Links umgehen kann, und diese Headerangabe so zu setzen ist im Prinzip nichts anderes, also verstehe ich auch die Verpflichtung zu absoluten URLs.

Olli

[Cheatah]

Hi,

Ach noch etwas, ich denke nicht das du ein Beispiel bringen kannst, weil jeder Browser auch mit relativen Links umgehen kann, und diese Headerangabe so zu setzen ist im Prinzip nichts anderes,

die Header-Angabe hat im Prinzip nicht das geringste mit Links zu tun. Die einzige Überschneidung ist, dass auch in Links absolute URLs erlaubt sind.

also verstehe ich auch die Verpflichtung zu absoluten URLs.

Damit haben wir also Deinen Irrtum entdeckt.

Cheatah

[Olli]

also verstehe ich auch die Verpflichtung zu absoluten URLs.

Damit haben wir also Deinen Irrtum entdeckt.

Ja mein Irrtum war anzunehmen,es wäre laut deiner Aussage wirklich ein kritischer Fehler, so wie ich das sehe, ist das lediglich eine Regel, an deren Unlogik kein Zweifel besteht.

Olli

[ChrisB]

Hi,

Ja mein Irrtum war anzunehmen,es wäre laut deiner Aussage wirklich ein kritischer Fehler, so wie ich das sehe, ist das lediglich eine Regel, an deren Unlogik kein Zweifel besteht.

Das ist die gleiche Argumentationslogik, wie das Anschnallen beim Autofahren abzulehnen - mit der Begruendung, dass ja auch ohne bisher "noch nie was passiert" sei.

MfG ChrisB

[Hans]

mmh, bei meinen Skripten war das bisher auch dasselbe, OBWOHL ich mit relativen Location-Angaben gearbeitet habe.
Dass laut Doku nur eine absolute Angabe zulässig ist erscheint mir ambivalent
(obwohl klar und deutlich so beschrieben),
da eben auch relative funktionieren.
Desweiteren, von Fehlermeldungen mal abgesehen, ist mir eine Sicherheitslücke
durch relative Angaben nicht ersichtlich.

Vielleicht haben wir es hier mit einem Paragraphenritt/reiter zu tun ;-)

MfG Hans

[Samoht]

Vielleicht haben wir es hier mit einem Paragraphenritt/reiter zu tun ;-)

Das glaube ich nicht. Ich stimme mit Cheatah dahingehend überein, dass (Programmier)-Fehler, die keine (ersichtliche) Auswirkung haben Fehler bleiben. Und das man diese im eigenen Interesse nicht "gutreden" sollte.

Abgesehen davon, dass Du noch keine Probleme erkennen konntest, wer garantiert Dir, dass das so bleibt?
Wenn jemand mit (meinetwegen dem zukünftigen IE8) plötzlich Deine Seiten nicht mehr öffnen kann, weil jener Browser warum auch immer relative Pfade einfach nicht mehr mag - wen machst Du dann dafür verantwortlich? Microsoft?
Die biegen sich vor lachen...

Ergo: Lieber jetzt die Fehler beheben, als später bereuen, wenn zu spät!

Samoht

[Olli]

Hallo Hans,

Vielleicht haben wir es hier mit einem Paragraphenritt/reiter zu tun ;-)

mir erschliesst sich der Sinn auch nicht, bin aber wirklich mal neugierig darauf zu erfahren, wie sich dadurch ein Fehler produzieren lässt.

Denn irgendwas müssen sich die Entwickler ja dabei gedacht haben.

Gruss
Olli

[Cheatah]

Hi,

Doch hast du behauptet, zitat:

Zitate sinnentfremdend zu kürzen nennt man "lügen".

Ich kann Dir nur das Gegenteil garantieren.
Das glaube ich Dir nicht, wie ich schon sagte, laufen meine Scripte seit Jahren mit diesem *Fehler, ohne dass je ein Browser versagt hätte.

Klar, Du hast sie ja auch alle jedes Mal beobachtet. Übrigens sehe ich keinen Grund, weshalb man das Problem auf Browser beschränken sollte. Es betrifft *alle* HTTP-Clients.

Wenn du nun meinst ich sollte diese fehlerhaften Files alle aufspüren und korregieren, dann werde ich das(auch wenn das Monate dauern wird)tun.

Ja, das meine ich.

Aber nur wenn das wirklich ein Risiko birgt, wovon du mich bisher nicht wirklich überzeugen konntest. Ein kleines Beispiel würde mir reichen.

Ein Beispiel? Nun gut. Man nehme einen standardkonformen HTTP-Client. Es ist bekannt, dass dieser absolute URLs im Location-Header verwerten kann, denn er ist ja standardkonform. Mit relativen URLs kann er jedoch nichts anfangen, denn der Standard verlangt zwingend eine absolute URL; also wurde dieser Fall, der nicht vorkommen kann, auch nicht vorgesehen.

Ganz einfach.

Cheatah

[Olli]

Hi,

Doch hast du behauptet, zitat:

Zitate sinnentfremdend zu kürzen nennt man "lügen".

du stehst nicht gern zu fehlerhaften Aussagen was ?

Ich kann Dir nur das Gegenteil garantieren.
Das glaube ich Dir nicht, wie ich schon sagte, laufen meine Scripte seit Jahren mit diesem *Fehler, ohne dass je ein Browser versagt hätte.

Klar, Du hast sie ja auch alle jedes Mal beobachtet. Übrigens sehe ich keinen Grund, weshalb man das Problem auf Browser beschränken sollte. Es betrifft *alle* HTTP-Clients.

Jedes Mal beobachtet? Dieses Anzweifeln ist nicht dein wirklicher Ernst, oder?

Wenn du nun meinst ich sollte diese fehlerhaften Files alle aufspüren und korregieren, dann werde ich das(auch wenn das Monate dauern wird)tun.

Ja, das meine ich.

»»

Aber nur wenn das wirklich ein Risiko birgt, wovon du mich bisher nicht wirklich überzeugen konntest. Ein kleines Beispiel würde mir reichen.

Ein Beispiel? Nun gut. Man nehme einen standardkonformen HTTP-Client. Es ist bekannt, dass dieser absolute URLs im Location-Header verwerten kann, denn er ist ja standardkonform. Mit relativen URLs kann er jedoch nichts anfangen, denn der Standard verlangt zwingend eine absolute URL; also wurde dieser Fall, der nicht vorkommen kann, auch nicht vorgesehen.

Ganz einfach.

Einfach? Das soll ein Beispiel sein? Hinkt aber gewaltig.
So ein HTTP-Client würde nicht zu meinen erwünschten Besuchern gehören und wäre wohl eher was für'n Müll, denn für sonst was, denn in diesem Fall fielen auch alle anderen relativen Verweise weg: Links, Bilder, Dateien, usw....

Sag mal, hängt deine Argumentation irgendwie mit dem heutigen Datum zusammen?

Olli

[Harlequin]

Yerf!

Einfach? Das soll ein Beispiel sein? Hinkt aber gewaltig.
So ein HTTP-Client würde nicht zu meinen erwünschten Besuchern gehören und wäre wohl eher was für'n Müll, denn für sonst was, denn in diesem Fall fielen auch alle anderen relativen Verweise weg: Links, Bilder, Dateien, usw....

Was nun, wenn im IE ein Bug in Verbindung mit relativen URLs in Location-Headern auftaucht und MS entscheidet dieses "Feature" zu deaktiviren statt zu fixen? schließlich ist das ja nicht Standardkonform...

Du hältst das für abwegig? Aber genau so lief es mit der Angabe von Benutzername und Passwort in URLs für HTTP. Da dort ein Bug enthalten war der zur Verschleierung von URLs genutzt werden konnte hat man das ganze einfach deaktiviert (statt den Bug zu fixen)...

Und was einen eventuellen Einwand wegen anderer relativer URLs angeht... die Angabe von Username und Passwort in FTP-URLs ist im IE weiterhin möglich (da ist es auch Standardkonform)...

Spätestens dann hättest du ein Problem, aber es kann dir schon jetzt keiner garantieren das es nicht zu Problemen kommt.

Gruß,

Harlequin

[Olli]

Hi,

deine Ausführung deckt sich mit meinen eigenen Befürchtungen in dieser Hinsicht. Das ist für mich aber jetzt kein Grund monatelange Arbeit in die Korregierung meiner Scripte zu setzen, weil die Wahrscheinlichkeit für diese Problematik zu gering erscheint und die dann eintreffenden Probleme keine ernsthaften wären, wie zb. eine Sicherheitslücke..

Spätestens dann hättest du ein Problem, aber es kann dir schon jetzt keiner garantieren das es nicht zu Problemen kommt.

Genau nur Cheatah wollte mir weismachen, das bereits jetzt solche Probleme auftreten. Und das ist nicht der Fall.

Aber natürlich war sein Hinweis trotzdem gewinnbringend, so dass meine zukünftigen location Anweisungen natürlich absolut sind.

Gruss
Olli

[Jens Holzkämper]

Tach,

Genau nur Cheatah wollte mir weismachen, das bereits jetzt solche Probleme auftreten. Und das ist nicht der Fall.

dir ist kein entsprechender Fall bekannt; das ist ein sehr großer Unterschied. Cheatah hatte ja schon Umstände genannt unter denen es im IE Probleme machen würde.

mfg
Woodfighter

[Olli]

Hi,

Genau nur Cheatah wollte mir weismachen, das bereits jetzt solche Probleme auftreten. Und das ist nicht der Fall.

dir ist kein entsprechender Fall bekannt; das ist ein sehr großer Unterschied. Cheatah hatte ja schon Umstände genannt unter denen es im IE Probleme machen würde.

Sollte ich da etwas verpasst haben? Beispiel?

Olli

[Jens Holzkämper]

Tach,

dir ist kein entsprechender Fall bekannt; das ist ein sehr großer Unterschied. Cheatah hatte ja schon Umstände genannt unter denen es im IE Probleme machen würde.

Sollte ich da etwas verpasst haben? Beispiel?

"Im IE klappt es übrigens nicht. Spätestens dann, wenn mehrere Redirects über Domaingrenzen hinweg gehen."

mfg
Woodfighter

[Olli]

Hi,

Sollte ich da etwas verpasst haben? Beispiel?

"Im IE klappt es übrigens nicht. Spätestens dann, wenn mehrere Redirects über Domaingrenzen hinweg gehen."

wenn ich das als gefahr ansehen soll, müsste ich auch alle Verweise im Context absolut setzen, die funktionieren schliesslich auch nicht über Domaingrenzen.

Olli

[Jens Holzkämper]

Tach,

wenn ich das als gefahr ansehen soll, müsste ich auch alle Verweise im Context absolut setzen, die funktionieren schliesslich auch nicht über Domaingrenzen.

ich weiß nicht, wann der Bug auftaucht, es könnte allerdings sein, dass deine Umleitung in einer Verkettung von Umständen die letzte Umleitung ist und dann nicht mehr funktioniert, Cheatah sprach ja von mehreren Umleitungen.

mfg
Woodfighter

[Klawischnigg]

Hi there,

ich weiß nicht, wann der Bug auftaucht, es könnte allerdings sein, dass deine Umleitung in einer Verkettung von Umständen die letzte Umleitung ist und dann nicht mehr funktioniert, Cheatah sprach ja von mehreren Umleitungen.

Und für so eine faule Chance sollte er hunderte Skripten editieren? Jeder, der so etwas täte, handelte ökonomisch höchst unverantwortlich...

[Jens Holzkämper]

Tach,

Und für so eine faule Chance sollte er hunderte Skripten editieren?

nein, ein solcher Fehler könnte schließlich auch noch anderswo auftreten.

Jeder, der so etwas täte, handelte ökonomisch höchst unverantwortlich...

kurzfristig betrachtet ja, langfristig betrachtet nein.

mfg
Woodfighter

[Klawischnigg]

Hi there,

Jeder, der so etwas täte, handelte ökonomisch höchst unverantwortlich...

kurzfristig betrachtet ja, langfristig betrachtet nein.

Wie heisst's so schön? Zu Tode gefürchtet ist auch gestorben...

[Hans]

mmmh.. mir würde immernoch das klare Beispiel fehlen, auch wenn bereits auf
vorherige Aussagen verlinkt wurde...

[Gunnar Bittersmann]

@@Klawischnigg:

Und für so eine faule Chance sollte er hunderte Skripten editieren? Jeder, der so etwas täte, handelte ökonomisch höchst unverantwortlich...

Was ist daran „ökonomisch höchst unverantwortlich“, wenn es sich doch in Sekundenschnelle erledigen lässt? [https://forum.selfhtml.org/?t=169103&m=1104525 ff.]

Live long and prosper,
Gunnar

[Klawischnigg]

Hi there,

Was ist daran „ökonomisch höchst unverantwortlich“, wenn es sich doch in Sekundenschnelle erledigen lässt? [https://forum.selfhtml.org/?t=169103&m=1104525 ff.]

Woher sollte das search_and_replace-Programm wissen, um welche Domains resp. URIs es sich handelt? Ohne es genauer zu wissen nehme ich einmal schwer an, daß es nicht jedesmal um die selbe geht...

[ChrisB]

Hi,

Woher sollte das search_and_replace-Programm wissen, um welche Domains resp. URIs es sich handelt?

Das soll es gar nicht wissen - sondern nur die entsprechenden PHP-Variablen vor die relative Pfadangabe setzen.

MfG ChrisB

[Klawischnigg]

Hi there,

Das soll es gar nicht wissen - sondern nur die entsprechenden PHP-Variablen vor die relative Pfadangabe setzen.

Hää?

Wenn ich header("Location: 404.php") durch einen absoluten Pfad ersetzen will, dann muß man den ja wohl kennen, oder?

[ChrisB]

Hi,

Wenn ich header("Location: 404.php") durch einen absoluten Pfad ersetzen will, dann muß man den ja wohl kennen, oder?

Noe.
PHP kennt ihn - in den entsprechenden Eintraegen in $_SERVER.

Also warum Festwerte eintragen, mit denen das ganze bei Umzug auf eine andere Domain oder eine andere Verzeichnisebene nicht mehr "funzt" - wenn man es auf diese Weise auch dynamisch halten kann.

MfG ChrisB

[Sven Rautenberg]

Moin!

Sollte ich da etwas verpasst haben? Beispiel?

"Im IE klappt es übrigens nicht. Spätestens dann, wenn mehrere Redirects über Domaingrenzen hinweg gehen."

wenn ich das als gefahr ansehen soll, müsste ich auch alle Verweise im Context absolut setzen, die funktionieren schliesslich auch nicht über Domaingrenzen.

Du verwechselst da was. In HTML darf in href- und src-Attributen selbstverständlich eine relative URL stehen.

Aber HTML ist ein ganz anderes Universum, als HTTP, in dem du mit Location-Headern PHP-seitig rumspielst.

Nur mal als ein Beispiel für "funktioniert auf wundersame Weise nicht" dieses Posting hier: http://www.webmasterworld.com/forum88/4890.htm.

Der IE6 macht Probleme mit relativen URLs, wenn gleichzeitig ein Login sein soll. Das Posting dort geht nicht genau darauf ein, wie das Login realisiert ist, aber mutmaßlich geht es um HTTP-Authentifizierung.

Und damit wäre der kritische Fall also schon eingetreten: Der IE6 ist ein verbreiteter Browser, Logins sind nicht selten, Redirects ebenfalls nicht - und beides läßt sich prima unabhängig voneinander implementieren, indem z.B. ein PHP-Skript mit relativem Redirect durch .htaccess geschützt wird.

- Sven Rautenberg

[Gunnar Bittersmann]

@@Olli:

Das ist für mich aber jetzt kein Grund monatelange Arbeit in die Korregierung meiner Scripte zu setzen

?? Monatelang? Hast du keinen Editor, der Suchen und Ersetzen in allen geöffneten Dateien unterstützt?

Damit ist das wohl Sache weniger Sekunden.

Live long and prosper,
Gunnar

[Samoht]

?? Monatelang? Hast du keinen Editor, der Suchen und Ersetzen in allen geöffneten Dateien unterstützt?

Damit ist das wohl Sache weniger Sekunden.

man braucht nicht mal geöffnete dateien:
http://www.inforapid.de/html/suchenersetzen.htm

Samoht

[Jens Holzkämper]

Tach,

man braucht nicht mal geöffnete dateien:
http://www.inforapid.de/html/suchenersetzen.htm

25 € für die funktionalität von sed halte ich für stark übertrieben.

mfg
Woodfighter

[Samoht]

25 € für die funktionalität von sed halte ich für stark übertrieben.

Ansichtssache. Abgesehen davon ist es Freeware für Privatanwender.

Bin offen für Vorschläge von Alternativsoftware mit ähnlichem Umfang.

Samoht

[Jens Holzkämper]

Tach,

Ansichtssache. Abgesehen davon ist es Freeware für Privatanwender.

Bin offen für Vorschläge von Alternativsoftware mit ähnlichem Umfang.

habe ich doch gemacht, sed ist vermutlich bereits mächtiger. Wenn sed nicht mehr reicht hilft gawk.

mfg
Woodfighter

[ChrisB]

Hi,

So ein HTTP-Client würde nicht zu meinen erwünschten Besuchern gehören und wäre wohl eher was für'n Müll, denn für sonst was, denn in diesem Fall fielen auch alle anderen relativen Verweise weg: Links, Bilder, Dateien, usw....

Du wirfst HTTP- und HTML-Client durcheinander.

MfG ChrisB

[steveq]

Vielen Dank erst mal.

Ich werd das mal durchspielen.

und  ich weiss auch nicht, in welchen Fällen es sein kann, dass die Header-Daten noch NICHT gesendet worden sind.

Vermutlich in allen, die für dieses Code-Fragment eine Rolle spielen.

Was meinst du damit? Bzw. auf welche Header wird denn getestet? Weil die Header-Funktion ist doch eine PHP-eigene. Damit muss doch festgelegt sein, welche Header geprüft werden, oder?

Danke

[ChrisB]

Hi,

und  ich weiss auch nicht, in welchen Fällen es sein kann, dass die Header-Daten noch NICHT gesendet worden sind.

Vermutlich in allen, die für dieses Code-Fragment eine Rolle spielen.
Was meinst du damit? Bzw. auf welche Header wird denn getestet?

Auf die HTTP Response Header.

Weil die Header-Funktion ist doch eine PHP-eigene.

Auch ohne, dass du header() benutzt, sendet PHP natuerlich selber HTTP Response Header - sonst muesstest du die ja *alle* in *jedem* Script selber ausloesen.

Damit muss doch festgelegt sein, welche Header geprüft werden, oder?

PHP schickt die HTTP Response Header spaetestens dann raus, wenn die erste "Ausgabe" erfolgt (das kann <html> sein, dass kann ein einzelnes Leerzeichen oder Newline sein, reiner Text, ...) - eben alles, was in den Response Body gehoert.
Deshalb kannst du in solchen Faellen header() dann nicht mehr benuzten [1], weil die Header schon rausgeschickt worden sind, und bekommst eine entsprechende Fehlermeldung - wenn du es eben nicht wie hier vorgemacht, vorher abfragst.

[1] Im Normalfall; output buffering hilft das zu "umgehen", was man aber eigentlich dafuer nie braucht, wenn man einen vernuenftigen Programmierstil (Stichwort: EVA-Prinzip) pflegt.

MfG ChrisB