Seite nicht auffindbar - Was tun?

[filigo]

Moin,

habe mal eine Frage bezüglich eurer Meinung zu folgendem Thema:
Was sollte man tun, wenn eine Seite (in dem Fall mit GET-Parameter-Ids) angefordert wird, die es nicht gibt?

• Nur einen 404 header senden und eine Seite ausgeben mit "gibts nicht"? Einfach davon ausgehen, dass ein User solche Seiten garnicht erst sehen sollte.
• Zu einer Suchseite mit header 404 umleiten und hier sagen "gibts nicht" und gleich nach den Parametern innerhalb des eigenen Webauftritts suchen? Hierbei wäre wenigstens kein Inhalt unter der falschen Url, also am besten eigtl noch einen 410 dann umleiten und dann 404 Suchseite?
• rechenaufwendige Ratespiele spielen und dem User auf eine mögliche Seite leiten?

Was meint ihr?

grüzi

[Beat]

Was sollte man tun, wenn eine Seite (in dem Fall mit GET-Parameter-Ids) angefordert wird, die es nicht gibt?

Rüchfrage: Die url enthält den echten Query, und keine mod_rewrite aufbereitete Pseudopfade?

• Nur einen 404 header senden und eine Seite ausgeben mit "gibts nicht"? Einfach davon ausgehen, dass ein User solche Seiten garnicht erst sehen sollte.

Differenziere url von querystring
Dateien die nicht _mehr_ existieren, kannst die in .htaccess mit 410 beantworten, solche die _nie_ existierten werden sowieso mit 404 beantwortet.

Bei Queries wird es etwas schwiieriger, weil es eher die Frage ist, was sollen Index-Robots indexieren und was nicht. Es macht keinen Sinn wenn sie temporäre Query-Strings indexieren. Also deaktiviert man solche Links für Bots.
Da du Id's erwähnst, ist es klug, solche Links vor Bots zu deaktivieren

Mehr Info bitte.

mfg Beat

[Sven Rautenberg]

Moin!

Bei Queries wird es etwas schwiieriger, weil es eher die Frage ist, was sollen Index-Robots indexieren und was nicht. Es macht keinen Sinn wenn sie temporäre Query-Strings indexieren. Also deaktiviert man solche Links für Bots.

Das sehe ich komplett anders. Wenn eine URL einen Querystring enthält, dann kann dieser nicht "temporär" sein, weil er eine dauerhafte URL bildet. Eventuell sind die damit abrufbaren Informationen temporärer Natur, weil sie sich je nach Datenlage ändern können. Das trifft aber genauso auf alle anderen Formen von URLs zu.

Da du Id's erwähnst, ist es klug, solche Links vor Bots zu deaktivieren

Frage: Wie erkennt man, dass ein Request von einem Bot kommt?

Antwort: Gar nicht, HTTP kennt nur Requests, unterscheidet nicht zwischen "Browser-Request" und "Bot-Request".

Folglich kann man auch nicht einfach "Links vor Bots deaktivieren".

- Sven Rautenberg

[Beat]

Bei Queries wird es etwas schwiieriger, weil es eher die Frage ist, was sollen Index-Robots indexieren und was nicht. Es macht keinen Sinn wenn sie temporäre Query-Strings indexieren. Also deaktiviert man solche Links für Bots.
Das sehe ich komplett anders. Wenn eine URL einen Querystring enthält, dann kann dieser nicht "temporär" sein, weil er eine dauerhafte URL bildet. Eventuell sind die damit abrufbaren Informationen temporärer Natur, weil sie sich je nach Datenlage ändern können. Das trifft aber genauso auf alle anderen Formen von URLs zu.

Weist du, wie Yahoo mit Query-Strings umgeht?
Da besteht dadurch ein Unterschied.
Die Praxis weicht oft von der Theorie ab.

Da du Id's erwähnst, ist es klug, solche Links vor Bots zu deaktivieren
Frage: Wie erkennt man, dass ein Request von einem Bot kommt?

Indem du dich auf das user-Agent-Feld für einmal verlässt. Es geht nicht um Sicherheit sondern um angemessene Effektivität.

Antwort: Gar nicht, HTTP kennt nur Requests, unterscheidet nicht zwischen "Browser-Request" und "Bot-Request".

Ach...

Folglich kann man auch nicht einfach "Links vor Bots deaktivieren".

• Sven Rautenberg

Ich habe Session Ids in Urls (ja ich kenne die Vor- und Nachteile), und ich kenne die sehr gefrässige Natur, vor allem von MSN.
Da es mir primär darum geht, hier die unnötige Last abzubauen, leiste ich es mir, mich in diesem Fall auf die User-Agent Strings zu verlassen und entsprechende Links für diese Bots zu deaktivieren. Übrig bleiben ihnen Bookmarklinks.

Um den Fall zu beurteilen braucht es mehr Info.

mfg Beat

[Sven Rautenberg]

Moin!

Was sollte man tun, wenn eine Seite (in dem Fall mit GET-Parameter-Ids) angefordert wird, die es nicht gibt?

Die Frage hat zwei Aspekte:

1. Welchen HTTP-Status sendet man?
2. Welchen Seiteninhalt liefert man mit?

• Nur einen 404 header senden und eine Seite ausgeben mit "gibts nicht"? Einfach davon ausgehen, dass ein User solche Seiten garnicht erst sehen sollte.
• Zu einer Suchseite mit header 404 umleiten und hier sagen "gibts nicht" und gleich nach den Parametern innerhalb des eigenen Webauftritts suchen? Hierbei wäre wenigstens kein Inhalt unter der falschen Url, also am besten eigtl noch einen 410 dann umleiten und dann 404 Suchseite?
• rechenaufwendige Ratespiele spielen und dem User auf eine mögliche Seite leiten?

Wenn du dem abrufenden Client mitteilen willst: "Die Seite gab es mal, aber die ist jetzt weg", dann sende Status "410 Gone".

Wenn du mitteilen willst: "Die Seite gibts nicht, du hast irgendwas falsch gemacht", dann sende Status "404 Not found".

Wenn du mitteilen willst: "Die Seite, die du willst, hat eine andere URL", dann sende Status "301 Moved permanently".

Und eventuell willst du auch sagen: "Die Seite, die du willst, gibts in dem Sinne wohl noch nicht, guck zwischenzeitlich mal diese andere URL an.", dann sende Status "302 Found".

Bei genauerer Betrachtung kommt eigentlich nur Status 404 für die allermeisten Situationen in Frage. Status 410 und 301 sind nur sinnvoll bei Seiten, die es früher mal gegeben hat - der eine für entfernte Seiten, der andere für Seiten, die jetzt eine neue URL haben (obwohl man sowas eigentlich vermeiden sollte, URLs sollen ewig gültig bleiben).

Bleiben nur noch 404 und 302. Temporäre Redirects sorgen dafür, dass Suchmaschinen die tatsächliche URL als gültig registrieren könnten - das will man auch nicht. Bleibt als einzig sinnvoller Status eben 404.

Davon unabhängig kann die mit dem Status mitgelieferte Seite ja gerne hilfreiche Informationen geben, auf welche Weise man die vermeintlich gewünschte Information dennoch erhalten könnte.

- Sven Rautenberg

[filigo]

Hallo,

vielen Dank für eure ausführlichen verständlichen Antworten.

Jedoch ein Teilaspekt meiner Frage ist noch unbeantwortet.

Sagen wir mal es wir eine Seite, die nicht vorhanden ist angefordert, also 404. Sendet man dann am besten den header und leitet sofort auf eine Seite "not found" weiter, oder soll unter der falschen Url dann mit dem 404 header schon die Information "not found" ausgegeben werden mit möglichen Tips, wie man den Inhalt trotzdem findet.

Bei ersterem wäre die Seite ja faktisch wirklich nicht existent, bei zweiterem würde man ja unter jeder noch so falschen Url zumindest eine Seite kriegen, wos heißt, dass was schief lief. Somit wäre die 404 Seite doppelter Content, weil die gleiche Seite unter mehreren Domains erreichbar ist.

Gruß

[Sven Rautenberg]

Moin!

Sagen wir mal es wir eine Seite, die nicht vorhanden ist angefordert, also 404. Sendet man dann am besten den header und leitet sofort auf eine Seite "not found" weiter, oder soll unter der falschen Url dann mit dem 404 header schon die Information "not found" ausgegeben werden mit möglichen Tips, wie man den Inhalt trotzdem findet.

Wenn du auf eine andere Seite weiterleitest, dann mußt du einen der Redirect-Statuscodes verwenden, andernfalls würde der Browser die neue Seite nicht laden.

Das wiederum bedeutet, dass du den Status 404 nicht ausgeben kannst. Der jedoch ist extrem wichtig für Suchmaschinen, denn nur daran erkennen sie, dass es die Seite nicht gibt. Würden sie den Redirect bekommen, würden das bedeuten, dass es die Seite gibt, die nur eine andere URL hat.

Redirects auf 404-Seiten (die Status 404 ausgeben) halte ich für sinnlos. Du weißt schon in dem Moment, wo du auf der ersten Seite entscheiden mußt, auf die 404-Seite weiterzuleiten, dass es die Seite nicht gibt. Warum dann noch weiterleiten?

- Sven Rautenberg

[Beat]

Das wiederum bedeutet, dass du den Status 404 nicht ausgeben kannst. Der jedoch ist extrem wichtig für Suchmaschinen, denn nur daran erkennen sie, dass es die Seite nicht gibt. Würden sie den Redirect bekommen, würden das bedeuten, dass es die Seite gibt, die nur eine andere URL hat.

Man muss bei Suchmaschinenen extrem Geduld haben, bis 404 eine Wirkung hat.
Die einzige verlässliche Antwort, die Suchmaschinen als "existiert nicht" sofort akzeptieren, ist ein 410.
Bei 404 interpretieren Suchmaschienen eher mal: "existiert derzeit nicht, aber wir behalten die Url trotzdem mal..."
Hat man dann in robots.txt noch einen Eintrag, dann behalten die Bots die url erst recht.

mfg Beat

[Sven Rautenberg]

Moin!

Das wiederum bedeutet, dass du den Status 404 nicht ausgeben kannst. Der jedoch ist extrem wichtig für Suchmaschinen, denn nur daran erkennen sie, dass es die Seite nicht gibt. Würden sie den Redirect bekommen, würden das bedeuten, dass es die Seite gibt, die nur eine andere URL hat.

Man muss bei Suchmaschinenen extrem Geduld haben, bis 404 eine Wirkung hat.
Die einzige verlässliche Antwort, die Suchmaschinen als "existiert nicht" sofort akzeptieren, ist ein 410.
Bei 404 interpretieren Suchmaschienen eher mal: "existiert derzeit nicht, aber wir behalten die Url trotzdem mal..."
Hat man dann in robots.txt noch einen Eintrag, dann behalten die Bots die url erst recht.

Gilt aber nur für Seiten, die schon mal existierten, denn bei Seiten, die nie existierten (und daher immer 404 waren), haben die Suchmaschinen nichts zum "behalten".

Vgl. meine Ausführungen zum Status 410 im ersten Posting dieses Zweiges.

- Sven Rautenberg

[filigo]

Hallo,

ich kann doch aber den Statuscode 404 senden und danach weiterleiten, dann erhält die Suchmaschine den 404?

410 bedeutet?

Gruß

[Sven Rautenberg]

Moin!

ich kann doch aber den Statuscode 404 senden und danach weiterleiten, dann erhält die Suchmaschine den 404?

Nein, kannst du nicht. Entweder Status 404 für "nicht gefunden", oder Status 301 bzw. 302 für "Weiterleitung". Nicht beides.

410 bedeutet?

Lies mein Posting aufmerksam durch, ich hatte die Erklärung bereits geliefert.

- Sven Rautenberg

[filigo]

Hallo,

ok 410 glatt überlesen.

Also wenn ich mir jetzt mal als Beispiel php herausgreife kann ich doch
header('HTTP/1.1 404 Not Found');
header('Location: http://example.com/');
schicken?

Also mit Moved Permanently mach ich das bei Seiten, die es mal gab und jetzt unter anderer Url erreichbar sind so.

Gruß

[Beat]

ok 410 glatt überlesen.
Also wenn ich mir jetzt mal als Beispiel php herausgreife kann ich doch
header('HTTP/1.1 404 Not Found');
header('Location: http://example.com/');
schicken?
Also mit Moved Permanently mach ich das bei Seiten, die es mal gab und jetzt unter anderer Url erreichbar sind so.

Ich als Client sehe von dir zuerst 404: Ich mache den Laden dicht. Vielleicht bin ich so nett und reiche den content an den user durch.
Es gibt für mich nichts mehr, was relevant wäre.
Sehe ich aber ein 301 oder 302, dann hat mich ein 404 gar nie erreicht.

Studieren deinen Server und dein PHP, was da los sein könnte.

mfg Beat

[filigo]

Hallo,

oh Missverständnis.

Ich verwenden
header('HTTP/1.1 301 Moved Permanently');
header('Location: http://example.com');

Ich wollte nur wissen, warum dies nicht bei einem 404 geht.
Aber ich kann ja 404 ausgeben und dann einfach eine Fehlerseite erreichbar machen. Zählt dies dann eigentlich nicht als doppelter Content, die Fehlerseite faktisch unendlich oft zur Verfügung zu stellen?

gruß

[Beat]

Ich wollte nur wissen, warum dies nicht bei einem 404 geht.
Aber ich kann ja 404 ausgeben und dann einfach eine Fehlerseite erreichbar machen. Zählt dies dann eigentlich nicht als doppelter Content, die Fehlerseite faktisch unendlich oft zur Verfügung zu stellen?

404 bedeutet "existiert nicht, alles weitere hat keine Relation zu der URI"
Das heisst, der content der Errormessage ist keine lokalisierbare Ressource.

mfg Beat

[Sven Rautenberg]

Moin!

oh Missverständnis.

Ich verwenden
header('HTTP/1.1 301 Moved Permanently');
header('Location: http://example.com');

Ich wollte nur wissen, warum dies nicht bei einem 404 geht.

Ich habe mal einen kurzen Blick in die HTTP-RFC geworfen.

Nirgendwo steht, dass der Location-Header nicht mit Status 404 kombiniert werden kann oder das sogar explizit verboten ist.

Allerdings läßt PHP allen der header()-Funktion übergebenen Strings noch eine Nachbehandlung angedeihen!

Im Detail:
1. Mehrfache Aufrufe von header() für denselben Header überschreiben sich gegenseitig (wenn man nicht explizit angibt, dass der Header zusätzlich sein soll, siehe den zweiten Parameter) - das gilt für alle Header-Strings.

2. Ein Header beginnend mit "HTTP/..." wird, egal welche Reihenfolge von Headern gesendet wurde, immer an den Anfang der Header gestellt.

3. Ein Location-Header sorgt immer dafür, dass gleichzeitig ein 302-Status gesendet wird, es sei denn, es wurde schon ein anderer 3xx-Status gesetzt.

Soweit die Theorie. Ich habe es dann mal kurz programmiert.

Erste Version:

<?php  
header("HTTP/1.1 404 not found");  
header("Location: http://www.example.com/");  
echo "404 not found";  
?>  

Resultat: wget -S http://www.example.org/test.php

HTTP request sent, awaiting response...
  HTTP/1.1 302 Found
  Date: Thu, 28 Aug 2008 15:26:58 GMT
  Server: Apache
  X-Powered-By: PHP/5.2.6-pl2-gentoo
  Location: http://www.example.com/
  Content-Length: 13
  Keep-Alive: timeout=15, max=100
  Connection: Keep-Alive
  Content-Type: text/html
Location: http://www.example.com/ [following]

wget zeigt also, dass vom Status 404 nichts übrig geblieben ist, stattdessen wird dem Redirect gefolgt.

Vertauscht man jetzt die beiden Headerzeilen, passiert sowas:

<?php  
header("Location: http://www.rautenberg.privat/");  
header("HTTP/1.1 404 not found");  
echo "404 not found";  
?>

HTTP request sent, awaiting response...
  HTTP/1.1 404 not found
  Date: Thu, 28 Aug 2008 15:30:11 GMT
  Server: Apache
  X-Powered-By: PHP/5.2.6-pl2-gentoo
  Location: http://www.example.com/
  Content-Length: 13
  Keep-Alive: timeout=15, max=100
  Connection: Keep-Alive
  Content-Type: text/html
  X-Pad: avoid browser bug
2008-08-28 17:30:11 ERROR 404: not found.

Die Location-Zeile ist zwar im Header drin, wget folgt dem Redirect aber NICHT. Auch mein Opera 9.50 und mein Firefox 3 verhalten sich genauso: Es wird einfach nur der per echo ausgegebene Text angezeigt, keinem Redirect gefolgt.

Selbst wenn also theoretisch ein 404 mit integriertem Redirect per Location-Header erlaubt wäre, so ist doch davon auszugehen, dass nahezu 100% aller derzeit existierenden HTTP-Clients dem Redirect nicht folgen werden - sowohl Browser, als auch Suchmaschinenspider.

Und es entbehrt auch nicht einer gewissen Logik, dass diese Kombination aus 404 und Redirect wegen innerer Unsinnigkeit nie wie von dir gewünscht ausgewertet werden wird.

Aber ich kann ja 404 ausgeben und dann einfach eine Fehlerseite erreichbar machen. Zählt dies dann eigentlich nicht als doppelter Content, die Fehlerseite faktisch unendlich oft zur Verfügung zu stellen?

Nun mach dir man erstmal nicht ins Hemd wegen "duplicate content". Suchmaschinen sind nicht komplett blöd, sowohl was die Negativbewertung von Spammern angeht, als auch was die Positiv-Wertung eines legitimen Content-Angebots angeht.

Welcher Information würdest du mehr Authentizität zugestehen: Wenn von irgendeiner Webseite irgendein Link auf deine Seite geht, dort eine nichtexistierende Seite referenziert, diese aber kein 404 ergibt, sondern z.B. eine Sitemap oder die Startseite mit Status 200, oder einen Redirect auf diese Seiten - und innerhalb deiner gesamten Sitenavigation taucht nirgendwo ein Link auf eben diese nichtexistente Seite auf - wer hat dann das bessere Wissen über nichtexistente Seiten, du oder diese andere Seite? Und wie würdest du als Suchmaschinenprogrammierer dann den Inhalt dieser nichtexistenten Seite einschätzen?

Suchmaschinen testen nämlich durchaus auch das Serververhalten bei Requests auf nicht existierende Ressourcen. Viele Server sind nämlich so programmiert, dass sie (dummerweise) gar keinen Status 404 rausrücken, sondern irgendwie immer mit einer Standardantwort ankommen. Durch den Test können die Spider dann unterscheiden, ob die Seite tatsächlich existiert, oder doch eher als 404 einzuschätzen ist.

Und sollte eine Suchmaschine wirklich den Content einer echten 404-Seite als "dupliziert" einstufen, würde das ja bedeuten, dass die Maschine die 404-Seite tatsächlich indizieren wollen würde - und das wäre nun wirklich idiotisches Verhalten. Es ist Standardzustand, dass es pro Server nur eine einzige 404-Seite gibt, und dass alle nichtexistenten URLs als "Inhalt" diese Standardseite haben.

- Sven Rautenberg

[Beat]

Hallo Sven

Ich bedanke mich mal für deinen ausführlichen Test.
Da habe ich mich also schadlos als "Client" aus dem Fenster gelehnt.

Meine Einschätzung der HTTP RFCs ist, dass sie keineswegs lückenlos sind. Sie geben zwar gut den generellen Ablauf wieder sowie die allgemeiner Syntax. Aber ein exaktes Ablaufschema für jeden Fall fehlt dort (wäre wohl auch nicht machbar).

Meine Auffassung ist (und hoffentlich bleibe ich hierbei nicht allein), dass der Statuscode wirklich viel darüber aussagt, wie mit weiteren header und content verfahren werden soll.
Dass bei einem 404 zum Beispiel der content an den User weitergegeben wird, ist für einen Browser sinnvoll, würde aber für einen Serverbasierten HTTP Request keinen Sinn machen. Dieser soll sich wirklich nur auf 404 verlassen.

Des weiteren wäre interessant: PHP gibts ja als Modul und als CGI. Perl wird praktisch nur als CGI betrieben. Hier gibt es meiner Ahnung nach verschiedene Interdependenzen zwischen dem Server und dem Prozess.

Wenn du ein Perlprogramm via CGI aufrufst, so ist der Aufruf allein bereits ein 200 Status wert. Woher kommt das? Es wird ja nicht vom Script extra eine Statuszeile geschrieben. Es ist (so meine Vermutung) Der Server, welcher den Response vorbelegt. Existiert das Script, und produziert es Output, dann ist das aus der Sicht des Servers ein 200er.

Ich habe schon versucht einen 404 Statuscode auszugeben, was aber fehl schlug (Fehler kann bei mir liegen). Es wurde brav 200 ausgegeben, wie das ja richtig ist. Solches Verhalten wäre mir auch erklärlich.

Suchmaschinen testen nämlich durchaus auch das Serververhalten bei Requests auf nicht existierende Ressourcen. Viele Server sind nämlich so programmiert, dass sie (dummerweise) gar keinen Status 404 rausrücken, sondern irgendwie immer mit einer Standardantwort ankommen. Durch den Test können die Spider dann unterscheiden, ob die Seite tatsächlich existiert, oder doch eher als 404 einzuschätzen ist.

Das ist genau das CGI Problem. Der Prozess kann nämlich ausgeführt werden, auch wenn ungültige Parameter Werte zur Ausgabe einer Standard-Seite führen.
Allerdings habe ich solche intelligente Test bei meinem Fall nicht feststellen können. MSN war hier am penetrantesten. bestimmte urls aus der Anfangszeit werden heute noch regelmässig angefordert.

mfg Beat

[Sven Rautenberg]

Moin!

Des weiteren wäre interessant: PHP gibts ja als Modul und als CGI. Perl wird praktisch nur als CGI betrieben. Hier gibt es meiner Ahnung nach verschiedene Interdependenzen zwischen dem Server und dem Prozess.

Wenn du ein Perlprogramm via CGI aufrufst, so ist der Aufruf allein bereits ein 200 Status wert. Woher kommt das? Es wird ja nicht vom Script extra eine Statuszeile geschrieben. Es ist (so meine Vermutung) Der Server, welcher den Response vorbelegt. Existiert das Script, und produziert es Output, dann ist das aus der Sicht des Servers ein 200er.

Ich habe schon versucht einen 404 Statuscode auszugeben, was aber fehl schlug (Fehler kann bei mir liegen). Es wurde brav 200 ausgegeben, wie das ja richtig ist. Solches Verhalten wäre mir auch erklärlich.

Es gibt Mittel und Wege, das auch mit Perl hinzukriegen, allerdings gibt es - richtig beobachtet - zwischen dem Perl-Skript und der letztendlichen Ausgabe an den Browser noch einige Zwischenschichten und Puffer, die an der produzierten Ausgabe herumwerkeln.

Meine Skripting-Anfänge haben vor Jahren auch mal mit Perl stattgefunden, und meine Erkenntnis aus dieser Zeit war folgende: Man kann auch mit Perl-Skripten "nackten, direkten" Zugang zum Browser erhalten, jedoch ist die Lösung dieses Problems alles andere als offensichtlich: Es hängt von der speziellen Benennung des Skripts ab! Wenn ein Skript mit den Zeichen "nph-" beginnt, ist es ein sogenanntes "non parsed header"-Skript und hat sich gemäß Definition zu 100% vollkommen selbst um das Senden geeigneter Header (inkl. Status) zu kümmern - dafür allerdings auch den Vorteil, dass keinerlei Ausgabepuffer den Datenfluß stören können.

Alle anderen Skripte kriegen durch die CGI-Umgebung von Perl eine Standardbelegung von Status und Headern vorgesetzt (bzw. teilweise nach Skriptende noch nachgereicht, wie z.B. Content-Length - schließlich wird die Skriptausgabe in einem Ausgabepuffer gehalten), und sämtliche vom Perl-Skript generierten HTTP-Header werden geparst und auf Korrektheit untersucht. Der Versuch, einen HTTP-Status einfach mit "HTTP/1.1 404 not found" zu printen, wird wohl von der CGI-Umgebung unterbunden. Vermutlich dürfte ein "Status: 404"-Header mehr fruchten... Aber für Perl-CGIs bin ich wirklich nicht der zu befragende Experte. :)

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Es hängt von der speziellen Benennung des Skripts ab! Wenn ein Skript mit den Zeichen "nph-" beginnt, ist es ein sogenanntes "non parsed header"-Skript

Skript-DATEINAME ist gemeint - nicht irgendein Text im Skript selbst... Nur falls das noch nicht deutlich genug formuliert war.

- Sven Rautenberg

[Beat]

Es gibt Mittel und Wege, das auch mit Perl hinzukriegen, allerdings gibt es - richtig beobachtet - zwischen dem Perl-Skript und der letztendlichen Ausgabe an den Browser noch einige Zwischenschichten und Puffer, die an der produzierten Ausgabe herumwerkeln.

... Man kann auch mit Perl-Skripten "nackten, direkten" Zugang zum Browser erhalten, jedoch ist die Lösung dieses Problems alles andere als offensichtlich: Es hängt von der speziellen Benennung des Skripts ab! Wenn ein Skript mit den Zeichen "nph-" beginnt, ist es ein sogenanntes "non parsed header"-Skript und hat sich gemäß Definition zu 100% vollkommen selbst um das Senden geeigneter Header (inkl. Status) zu kümmern - dafür allerdings auch den Vorteil, dass keinerlei Ausgabepuffer den Datenfluß stören können.

Also zum Beispiel
   nph-myscript.pl
   nph-myscript.php
Das Umgehen des Puffers hat ja noch weitere Folgen, ausser das man sich um korrekte Header (Schwitz!) selbst kümmern muss.
Hab da jetzt etwas rumgesucht und das gefunden.
http://www.wdvl.com/Authoring/Scripting/Tutorial/nph.html
Ist ja vor allem praktisch, für chatscripte etc...
%ENV ist aber denoch vorhanden. nph heisst also nicht etwa, frei von allen CGI Dienstleistungen.

mfg Beat

[Sven Rautenberg]

Moin!

Also zum Beispiel
   nph-myscript.pl
   nph-myscript.php
Das Umgehen des Puffers hat ja noch weitere Folgen, ausser das man sich um korrekte Header (Schwitz!) selbst kümmern muss.
Hab da jetzt etwas rumgesucht und das gefunden.
http://www.wdvl.com/Authoring/Scripting/Tutorial/nph.html
Ist ja vor allem praktisch, für chatscripte etc...
%ENV ist aber denoch vorhanden. nph heisst also nicht etwa, frei von allen CGI Dienstleistungen.

Wie mir scheint, ist mein Wissen über die Notwendigkeit von "nph-" veraltet. Schon seit Apache 1.3 soll dieses Feature nicht mehr notwendig sein.

- Sven Rautenberg