dynamische Fehlerseite & htaccess

[Paul Brunner]

Hallo zusammen,

für Webseiten mit "Vergangenheit" habe ich mal ein php-Script geschrieben, das in Abhänigkeit von der nicht gefundenen Adresse
automatische auf die passende neue Adresse umleitet.

Das ganz ging mit untenstehendem .htaccess- und php-file wunderbar bis ich es auf einem anderen Server benutzen wollte.

.htaccess:
*-----
ErrorDocument 404 /redirect.php
*-----

redirect.php
*-----
<?php
function selectDirect($oldLink)
{
     [...]
 return $newlink;
}

header ("Location: http://".selectDirect(getenv(REQUEST_URI)));
exit;
?>
*-----

REQUEST_URI ist korrekt belegt, die Funktion gibt die korrekte neue Adresse aus, aber der header-Aufruf endet mit einer weissen Seite im Eieruhr-Nirvana.

Es muss also ein Konfigurations-Problem sein. Weiß jemand Rat?

Danke
Paul

[Cheatah]

Hi,

REQUEST_URI ist korrekt belegt, die Funktion gibt die korrekte neue Adresse aus, aber der header-Aufruf endet mit einer weissen Seite im Eieruhr-Nirvana.

hast Du dazu 'ne Test-URL?

Es muss also ein Konfigurations-Problem sein. Weiß jemand Rat?

Hm, dass Du vor dem Header keinerlei anderen Ausgaben machen darfst, auch keine Leerzeichen oder Umbrüche, ist Dir sicher bekannt... :-)

Cheatah

[Paul Brunner]

Hallo Cheatah,

hast Du dazu 'ne Test-URL?

ja:
http://www.arge-dlrg.de/mcbild
sollte auf
http://www.arge-dlrg.de/project/mcbild/
umgeleitet werden.

Hm, dass Du vor dem Header keinerlei anderen Ausgaben machen darfst, auch keine Leerzeichen oder Umbrüche, ist Dir sicher bekannt... :-)

Ja, das ist bekannt. php würde das aber auch mit einer Fehlermeldung quittieren.

Paul

[Cheatah]

Hi,

http://www.arge-dlrg.de/mcbild
sollte auf
http://www.arge-dlrg.de/project/mcbild/
umgeleitet werden.

hm, mein Testscript landet auf http://www.arge-dlrg.de/notfound.html, welches es offenbar nicht gibt... was eine wunderbare Endlosschleife ergibt ;-) Sieh doch mal nach, ob die Konfigurationsdatei überhaupt beachtet wird, und ob sie nicht anderweitig einen Fehler erzeugt.

Cheatah

[Andreas]

Hi!
Das Problem könnte an einer neueren PHP-Version liegen, das hatte ich auch mal, ich glaube der Bug ist noch nicht behoben und nur dadurch zu umgehen, das Du in die htaccess einen absoluten Link schreibst, also http://www.seerver.de/fehler.php

Grüße
Andreas

[Cheatah]

Hi,

Das Problem könnte an einer neueren PHP-Version liegen, das hatte ich auch mal,

kannst Du dazu mehr sagen? URLs?

ich glaube der Bug ist noch nicht behoben und nur dadurch zu umgehen, das Du in die htaccess einen absoluten Link schreibst, also http://www.seerver.de/fehler.php

Dann fällt REQUEST_URI resp. REDIRECT_URI weg, was in diesem Fehlerscript jedoch benötigt wird.

Cheatah

[Andreas]

Hi,

Das Problem könnte an einer neueren PHP-Version liegen, das hatte ich auch mal,

kannst Du dazu mehr sagen? URLs?

leider nein. Hatte mir mal ein techniker von meinem Provider gesagt, und es stimmte, wenn ich absolute Pfade nahem gings, doer halt html Error docs ging auch, naja!

ich glaube der Bug ist noch nicht behoben und nur dadurch zu umgehen, das Du in die htaccess einen absoluten Link schreibst, also http://www.seerver.de/fehler.php

Dann fällt REQUEST_URI resp. REDIRECT_URI weg, was in diesem Fehlerscript jedoch benötigt wird.

tja... das problem habe ich auch!!! Sehr schade eigentlich, außerdem wird die Adresse in der Adressleiste umgeschrieben.

Grüße
Andreas

[Andreas]

Hallo nochmal!
Nur so allgemein, mein Problem(und das vieler anderer) war, dass die dollsten Dinge passierten, wenn man in der htaccess PHP-Dateien als Errordocs hatte! Meistens wurde die eigene 404 Seite nicht angezeigt, nur wenn vorhanden die das Apache, manchmal aber auch die des IE, und auch ganz andere Error-Codes(500...), und das alles immer bei den gleichen Leuten immer mit der gleichen Software und bei unveränderten Scripten. Bei mir persönlich kamen nur an Stelle der Error-Docs die Standard-Server Error-Docs, das hörte sich halt so ähnlich und war nur durch html Docs oder durch absolute Pfade zu beheben ist(war) - mit allen Konsequenzen!
Grüße
Andreas

[Cheatah]

Hi,

Nur so allgemein, mein Problem(und das vieler anderer)

hat der Techniker irgendwas über die Ursache gesagt?

Meistens wurde die eigene 404 Seite nicht angezeigt, nur wenn vorhanden die das Apache, manchmal aber auch die des IE,

Hoppla, das würde mich aber schon sehr wundern, wenn mein Netscape plötzlich die Fehlerseite des IE anzeigt *g*

Cheatah

[Andreas]

Hi!

hat der Techniker irgendwas über die Ursache gesagt?

Das war ein PHP-Update. Der Provider hatte selber als Standard für alle Virtuellen Server eigene php-errordokumente als Standard in das Hauptverzeichnis gelegt, und auch gingen nicht mehr, daher wurde es leider auf html umgestellt. Jedenfalls war nur die PHP-Version upgedatet worden(ich glaube auf 4.1.2), sonst nix, und von heute auf morgen gingen die meisten PHP-Errordokumente nicht mehr, bei allen Kunden des Providers, und das ist schon ärgerlich sowas :-)
Mit den absoluten Pfaden oder html ging es dann. Danach habe ich davon nix mehr gehört, muß ich demnächst nochmal probieren. ich habe auch keine Ahnung wo solche Sachen gepostet werden oder wo solche Bugs stehen.

Ich habe gerade nochmal probiert, sektsamerweise funktioniert es jetzt auch nicht mehr mit dr htm Version... sehr seltsam, dann hat das ja gar nicht smit PHP zu tun! Naja, versteh das nicht.

Damit Du mir glaubst, die Dateien und den Code:

http://www.knet-systems.de/test/ht1/quatsch
htaccess:
ErrorDocument 404 /fehler.php

http://www.knet-systems.de/test/ht2/quatsch
htaccess:
ErrorDocument 404 http://www.knet-systems.de/test/ht2/fehler.php

http://www.knet-systems.de/test/ht3/quatsch
htaccess:
ErrorDocument 404 /fehler.html

Die einzelnen Fehlerdateien kannst Du sonst öffnen.

Verstehst Du das?
Grüße
Andreas

PS: Es kommt ja ein 404 zurück, aber zumindest im IE wird das eine mal zur Error-Seite weitergeleitet, das andere mal nur die IE Standarseite angezeigt.

[Cheatah]

Hi,

hat der Techniker irgendwas über die Ursache gesagt?
Das war ein PHP-Update. [...]

danke. Ich erinnere mich gerade dumpf, dass bei der CGI-Variante von PHP obskure Dinge passieren konnten; etwa wurde dann "bla/php.exe/fehlerdatei" oder so ähnlich nicht gefunden. Könnte das in die ähnliche Richtung gehen? Ist bei Deinem Provider PHP als CGI oder als Servermodul installiert?

Damit Du mir glaubst, die Dateien und den Code:

Ich glaube Dir schon :-) aber es ist doch interessant zu sehen. Insbesondere dies:

http://www.knet-systems.de/test/ht3/quatsch
ErrorDocument 404 /fehler.html

wundert mich, zumal die /fehler.html existiert...

Verstehst Du das?

Nein :-)

PS: Es kommt ja ein 404 zurück,

Nicht bei der zweiten Variante, da ist der Status (korrekt) 200.

aber zumindest im IE wird das eine mal zur Error-Seite weitergeleitet, das andere mal nur die IE Standarseite angezeigt.

Wie hast Du Deinen IE konfiguriert? Ich empfehle, die folgende Checkbox zu entfernen:

Extras / Internetoptionen / Erweitert
[ ] Kurze HTTP-Fehlermeldungen

Cheatah

[Andreas]

Hallo!

danke. Ich erinnere mich gerade dumpf, dass bei der CGI-Variante von PHP obskure Dinge passieren konnten; etwa wurde dann "bla/php.exe/fehlerdatei" oder so ähnlich nicht gefunden. Könnte das in die ähnliche Richtung gehen? Ist bei Deinem Provider PHP als CGI oder als Servermodul installiert?

CGI! Aber das war alles nichts offizielles. Und da unten das mit html auch nicht geht, zweifel ich langsam an dieser Erklärung! PHP Version ist 4.1.2

PS: Es kommt ja ein 404 zurück,

Nicht bei der zweiten Variante, da ist der Status (korrekt) 200.

:-)

Aber um das Chaos zu komplettieren:

http://www.knet-systems.de/test/ht4/quatsch

Da liegt keine .htaccess, das macht dann der Apache selbst, sind htm-Dateien im nicht http-Bereich ;-)

Wie hast Du Deinen IE konfiguriert? Ich empfehle, die folgende Checkbox zu entfernen:

Extras / Internetoptionen / Erweitert
[ ] Kurze HTTP-Fehlermeldungen

Ja, das kenne ich, aber ich gucke immer ganz gerne "durch das Auge des 08/15 Users"! Und ich kann ja schlecht auf die Startseite schreiben "bitte 'Kurze Fehlermeldungen' im IE deaktivieren, da sonst die Errordokumente nicht korrekt funktionieren..." Du verstehst was ich meine, oder?

Grüße
Andreas

PS: Ich wende mich nochmal an meine Technik, mal schaun was die dazu sagen!!! Das komische

[Michael Schröpl]

Hi,

Da liegt keine .htaccess, das macht dann der Apache
selbst, sind htm-Dateien im nicht http-Bereich ;-)

diese Aussage erschließt sich mir nicht. Auch die
Interpretation von .htaccess macht "der Apache selbst".
Ob eine Anweisung in der zentralen httpd.conf steht
oder in einer .htaccess, ändert nichts daran, daß sie
korrekt sein sollte.

Extras / Internetoptionen / Erweitert
[ ] Kurze HTTP-Fehlermeldungen
Ja, das kenne ich, aber ich gucke immer ganz gerne
"durch das Auge des 08/15 Users"! Und ich kann ja
schlecht auf die Startseite schreiben "bitte 'Kurze
Fehlermeldungen' im IE deaktivieren, da sonst die
Errordokumente nicht korrekt funktionieren..." Du
verstehst was ich meine, oder?

Du kannst aber Deine Fehlerseite länger machen - denn
ab 512 Bytes aufwärts ist sie für den M$IE nicht mehr
"kurz". Das ist eine Stelle, an der man nicht das
letzte Byte sparen sollte ...

Viele Grüße
      Michael

[Andreas]

Hallo!

diese Aussage erschließt sich mir nicht. Auch die
Interpretation von .htaccess macht "der Apache selbst".
Ob eine Anweisung in der zentralen httpd.conf steht
oder in einer .htaccess, ändert nichts daran, daß sie
korrekt sein sollte.

Sollte... dsas ist klar! Aber irgendwas stimmt nicht! Im vierten Ordner ist keine .htaccess Datei (und auch in keinem mir zugänglichen höheren Verzeichnis!), sondern da werden Standard-Error-Dokumente ausgegeben, die ich zwar verändern kann, aber nicht verlegen oder umbenennen. Das sind übrigens html Dateien. Ich habe gerade alle 3 htaccess-Dateien nochmal überprüft - das war alles korrekt.

Du kannst aber Deine Fehlerseite länger machen - denn
ab 512 Bytes aufwärts ist sie für den M$IE nicht mehr
"kurz". Das ist eine Stelle, an der man nicht das
letzte Byte sparen sollte ...

stimmt, hatte ich auch schon gehört, ändert aber auch nix:

relativer Link aus .htaccess zu /fehler.php: http://www.knet-systems.de/test/ht1/quatsch

absoluter Link aus .htaccess zu http://www.knet-systems.de/test/ht2/fehler.php: http://www.knet-systems.de/test/ht2/quatsch

relativer Link aus .htaccess auf /fehler.html: http://www.knet-systems.de/test/ht3/quatsch

keine .htaccess: http://www.knet-systems.de/test/ht4/quatsch

Ich weiß auch nicht, aber jetzt sollten ja wenigstens die error-Dokumente groß genug sein, oder?

Grüße
Andreas

[Cheatah]

Hi,

kannst Du dazu mehr sagen? URLs?
leider nein.

sehr schade.

Dann fällt REQUEST_URI resp. REDIRECT_URI weg, was in diesem Fehlerscript jedoch benötigt wird.
tja... das problem habe ich auch!!! Sehr schade eigentlich, außerdem wird die Adresse in der Adressleiste umgeschrieben.

Beide Effekte basieren auf dem selben Umstand, dass bei absoluten URLs kein serverinterner Redirect durchgeführt werden kann, sondern eine entsprechende HTTP-Information zurück zum Client geschickt wird, welcher dann seinerseits den neuen Roundtrip durchführt.

Cheatah

[Paul Brunner]

Hallo Andreas,

» Das Problem könnte an einer neueren PHP-Version liegen, das hatte ich auch mal, ich glaube der Bug ist noch nicht behoben und nur dadurch zu umgehen, das Du in die htaccess einen absoluten Link schreibst, also http://www.seerver.de/fehler.php

Ich denke der Fehler ist schon recht gut eingegrenzt. redirect.php wir korrekt aufgerufen und abgearbeitet, abgesehen vom header-Aufruf.

Ersetzt man im Beispielcode

*----
header ("Location: http://".selectDirect(getenv(REQUEST_URI)));
exit;
*----

durch

*----
print "old: ".getenv(REQUEST_URI)."<br>";
print "new: ".selectDirect(getenv(REQUEST_URI));
exit;
*----

kommen die erwarteten Werte heraus. Nur die Weiterleitung tut nicht.

Paul

[Paul Brunner]

Uuups,

Doppelfehler beim zusammenstellen der Beispieles jetzt
sollte es gehen, sprich den eigentlichen Fehler zeigen.

old: http://www.arge-dlrg.de/mcbild
new: http://www.arge-dlrg.de/project/mcbild/
default: http://www.arge-dlrg.de/notfound.html

Paul

[Cheatah]

Hi,

Doppelfehler beim zusammenstellen der Beispieles jetzt
sollte es gehen, sprich den eigentlichen Fehler zeigen.

es wird weiterhin Status: 404 ausgegeben. Versuch mal, den manuell auf 301 umzubiegen.

Cheatah

[Paul Brunner]

es wird weiterhin Status: 404 ausgegeben. Versuch mal, den manuell auf 301 umzubiegen.

ääääh, wie jedet dat?

[Cheatah]

Hi,

es wird weiterhin Status: 404 ausgegeben. Versuch mal, den manuell auf 301 umzubiegen.
ääääh, wie jedet dat?

bei einem "normalen" CGI-Einsatz würde ich einfach als ersten Header "Status: 301 Hat Sich Das Location Umgebiegt" ausgeben. Ob das (und wenn ja, unter welchen Bedingungen) bei PHP in die Hose geht, habe ich noch nicht getestet.

Cheatah

[Sönke Tesch]

http://www.arge-dlrg.de/mcbild
sollte auf
http://www.arge-dlrg.de/project/mcbild/
umgeleitet werden.

hm, mein Testscript landet auf http://www.arge-dlrg.de/notfound.html, welches es offenbar nicht gibt... was eine wunderbare Endlosschleife ergibt ;-)

Also ich sehe hier mit Mozilla genau das beschriebene Problem, eine leere Seite unter www.arge-dlrg.de/mcbild. Der IE 5 spuckt mir nach ein paar Sekunden Bedenkzeit einen 404 aus. Per telnet bekomme ich allerdings durchaus den erwarteten 404 zusammen mit der neuen Adresse in Location. Bedeutet: Skript funktioniert, Problem woanders.

Ich möchte deshalb mal auf ein prinzipielles Problem hinweisen: Der 404 ist keine Weiterleitung. Oder anders ausgedrückt: Diese Skriptlösung ist IMHO schon vom Ansatz her falsch.
Es würde mich daher nicht wundern, wenn die Browser aus diesem Grund mit der Location:-Kopfzeile nichts anfangen können.

Wenn überhaupt, müsste das Skript schon einen 301 zurückliefern, um tatsächlich brauchbar anzuzeigen, daß das Dokument an einer anderen Stelle liegt und dorthin bitte weitergeleitet werden soll - genau dazu ist schließlich 301 da, nicht 404 + Location.

Ich für meinen Teil würde die ganze merkwürdige Konstruktion aus verkapptem 404 und Wasserkopf PHP rausnehmen und stattdessen ganz einfach in die .htaccess die entsprechenden RedirectPermanent-Zeilen einfügen (gibt's auch als RedirectMatch mit Musterbearbeitung). _Das_ nenne sinn- und maßvollen Einsatz von Servertechnologie :)

Gruß,
  soenk.e

[Paul Brunner]

Hallo Sönke,

Ich für meinen Teil würde die ganze merkwürdige Konstruktion aus verkapptem 404 und Wasserkopf PHP rausnehmen und stattdessen ganz einfach in die .htaccess die entsprechenden RedirectPermanent-Zeilen einfügen (gibt's auch als RedirectMatch mit Musterbearbeitung).

Leider folgt die Zuordung alt->neu keinem festen Muster (RedirectMatch scheidet also aus), ich habe das ganze über eine Array gelöst. Lässt sich das trotzdem per 301 aufrufen?

Paul

P.S.
Bevor mich mein Provider ob des wiederholten produzierens von Endlosschleifen vierteilt, hab ich die Beispielseite runtergenommen.
(Dein Diagnose ist ja präzise genug)

[Sönke Tesch]

Ich für meinen Teil würde die ganze merkwürdige Konstruktion aus verkapptem 404 und Wasserkopf PHP rausnehmen und stattdessen ganz einfach in die .htaccess die entsprechenden RedirectPermanent-Zeilen einfügen (gibt's auch als RedirectMatch mit Musterbearbeitung).

Leider folgt die Zuordung alt->neu keinem festen Muster (RedirectMatch scheidet also aus), ich habe das ganze über eine Array gelöst. Lässt sich das trotzdem per 301 aufrufen?

Einfach ein

header("HTTP/1.0 301 Moved permanently");

oben einfügen und dann Dein Location-Ding hinterher. Ist auch in der Anleitung zur Funktion header() beschrieben.

Ich weiß nun natürlich nicht, wie lang Deine Liste ist, aber ich würd's trotzdem mit mehreren Redirects probieren. Bei dieser ErrorDocument404/PHP-Geschichte ist mir irgendwie unwohl :)

Gruß,
  soenk.e

[Paul Brunner]

Hallo Sönke,

Ich weiß nun natürlich nicht, wie lang Deine Liste ist, aber ich würd's trotzdem mit mehreren Redirects probieren. Bei dieser ErrorDocument404/PHP-Geschichte ist mir irgendwie unwohl :)

Mir war nicht bewusst, daß diese Funktionalität "vergewaltige".

In der php-Dokumentation habe ich dann nochmal nachgelesen und da steht folgendes:

"The second special case is the "Location:" header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless some 3xx status code has already been set.

header("Location: http://www.example.com/"); /* Redirect browser */
exit;                 /* Make sure that code below does
                         not get executed when we redirect. */ "

Also ist das doch das richtige?

Gruß
Paul

[Sönke Tesch]

Bei dieser ErrorDocument404/PHP-Geschichte ist mir irgendwie unwohl :)

Mir war nicht bewusst, daß diese Funktionalität "vergewaltige".

Immer diese lauwarmen Ausreden ;)

In der php-Dokumentation habe ich dann nochmal nachgelesen und da steht folgendes:

"The second special case is the "Location:" header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless some 3xx status code has already been set.

Also ist das doch das richtige?

Tja, ich hatte wie gesagt Deinem Server mal auf den Zahn gefühlt und dabei festgestellt, daß er zwar das Location schickt, aber zusammen mit einem 404. Da freut es mich, daß ich angesichts Deines Anleitungszitats mit meinem Unwohlsein dann tatsächlich nicht falsch lag: In der Verbindung ErrorDocument404/Location funktioniert dieses automatische Senden eines Weiterleitungscodes anscheinend nicht.

Gruß,
  soenk.e

[Cheatah]

Hi,

Also ich sehe hier mit Mozilla genau das beschriebene Problem, eine leere Seite unter www.arge-dlrg.de/mcbild.

mittlerweile schon. Und Mozilla verhält sich völlig richtig, denn:

Der 404 ist keine Weiterleitung.

Genau ;-) Es kommt ein File Not Found ohne Content, der Location-Header wird nicht beachtet. Warum der IE dafür länger braucht, verstehe ich nicht; aber vermutlich hat das auch nichts zu sagen.

ganz einfach in die .htaccess die entsprechenden RedirectPermanent-Zeilen einfügen (gibt's auch als RedirectMatch mit Musterbearbeitung).

Wenn das über einfache Pattern geht, stimme ich voll und ganz zu.

Cheatah

[Paul Brunner]

so funktioniert´s:

*----
header ("Status: 301 Moved Permanently\r\nLocation:http://".selectDirect(getenv(REQUEST_URI)));
exit;
*----

Danke für´s testen und anregen
Paul

[Sönke Tesch]

so funktioniert´s:

*----
header ("Status: 301 Moved Permanently\r\nLocation:http://".selectDirect(getenv(REQUEST_URI)));
exit;
*----

<nörgel>

Ein "Status" ist AFAIK nicht im HTTP-Protokoll definiert und wird anscheinend nur von PHP wegen der Uraltversion PHP 3 intern umgesetzt. In dem Zusammenhang dann auch noch zwei Zeilen an header() zu übergeben, wovon in der Anleitung nun überhaupt nix steht, halte ich für..naja..Glatteis :) Und ein Leerzeichen nach dem Doppelpunkt ist laut RFC 2616 auch ganz nett.

Mach's doch lieber gleich ganz richtig und schick

header("HTTP/1.0 301 Moved permanently");
header("Location: http://". undsoweiterunsofort..

</nörgel>

Nix für ungut ;)
  soenk.e

[Paul Brunner]

Hallo Sönke,

<verteidige mode="ein ganz klein wenig indigniert">

Ein "Status" ist AFAIK nicht im HTTP-Protokoll definiert und wird anscheinend nur von PHP wegen der Uraltversion PHP 3 intern umgesetzt.

Das ist richtig... Aber obwohl der Server php4.1.2 ausweist kommt ein
500 server-fehler, wenn ich mit "HTTP/1.0..." arbeite, mit "Status:..." gehts.

In dem Zusammenhang dann auch noch zwei Zeilen an header() zu übergeben, wovon in der Anleitung nun überhaupt nix steht, halte ich für..naja..Glatteis :)

Laut RFC 2616 Trennung der Headerzeilen mit CRLF. Da ich nicht wusste was die header-Funktion sonst noch so alles mitschickt, hab ich zur Sicherheit mal in einen Funktionsaufruf mit \r\n verwurstet. Mit zweien gehts auch.

Und ein Leerzeichen nach dem Doppelpunkt ist laut RFC 2616 auch ganz nett.

Wenn ich den erwische, der aus meinem Quellcode das Leerzeichen rausgemacht hat...;)

Mach's doch lieber gleich ganz richtig und schick

Oder halb-richtig aber funktionierend:
header("Status: 301 Moved permanently");
header("Location: http://". undsoweiterunsofort..

</verteidige>

Ich dank´ dir ;-)
Paul

P.S.: Eine Frage hätte ich doch noch: Was hat "301 Moved permanently" für einen Sinn? Wird es z.B. von Suchmaschinen genutzt um ihren Index aktuell zu halten?

[Sönke Tesch]

Ein "Status" ist AFAIK nicht im HTTP-Protokoll definiert und wird anscheinend nur von PHP wegen der Uraltversion PHP 3 intern umgesetzt.

Das ist richtig... Aber obwohl der Server php4.1.2 ausweist kommt ein
500 server-fehler, wenn ich mit "HTTP/1.0..." arbeite, mit "Status:..." gehts.

Mmh, man lernt nie aus. Unter 4.0.6 funktioniert's mit "HTTP/1.0"..

P.S.: Eine Frage hätte ich doch noch: Was hat "301 Moved permanently" für einen Sinn? Wird es z.B. von Suchmaschinen genutzt um ihren Index aktuell zu halten?

Wäre zum Beispiel sinnvoll. Unter http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2 ist das auch explizit so angegeben.

Gruß,
  soenk.e