Error: /usr/share/liveconfig/html/_404_

Bei mir auch

In /etc/apache2/sites-available/default :

Aus

<Directory "/usr/share/liveconfig/html/">
    Options SymLinksIfOwnerMatch IncludesNOEXEC
    AllowOverride None
    Order allow,deny
    allow from all
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteRule ^$  /[B]_404_[/B]
...

mach

<Directory "/usr/share/liveconfig/html/">
    Options SymLinksIfOwnerMatch IncludesNOEXEC
    AllowOverride None
    Order allow,deny
    allow from all
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteRule ^$  /[B]not-available.shtml[/B]
...

Das "_404_" steckt in der aktuellen Stable Version in

/usr/lib/liveconfig/lua/apache.lua:1035: RewriteRule ^$ /_404_

Ist das so gewollt?

Es handelt sich hier um kein Problem, dieses Verhalten ist beabsichtigt.
Auf die von LiveConfig konfigurierte Art wird ein 404-Fehler "erzwungen", wenn ein Besucher eine ungültige/unbekannte Domain aufruft. Mit dem o.g. Rewrite-Workaround auf die "/not-available.shtml" erhält der Besucher zwar die selbe Anzeige, aber mit einem HTTP-Status 200 statt 404.
Unserer Ansicht nach ist ein 404 der "richtigere" Statuscode, da ja letztendlich der angeforderte Inhalt nicht gefunden werden konnte. Das kann vor allem dann wichtig sein, wenn man z.B. die IP-Adressen einer Domain bereits auf einen LiveConfig-Server umgestellt hat, die Domain in LiveConfig aber noch nicht eingerichtet wurde. Wenn Suchmaschinen in diesem Fall die "Nicht verfügbar"-Website mit einem 200er Statuscode bekommen, wird diese Seite ganz normal in den Suchindex aufgenommen.

Fazit: der 404 erzeugt zwar eine Warnmeldung im error.log, ist aber völlig harmlos und (unserer Ansicht nach) sinnvoll. Sollte es dringende Gründe gegen dieses Verhalten geben, würde ich mich über eine entsprechende Diskussion freuen.

Viele Grüße

-Klaus Keppler

auch ich stolpere gerade darüber und bin hier ja schnell fündig geworden. tatsächlich bin ich auch der Meinung, das ein 404 sinnvoll ist, würde mir allerdings wünschen, die log-einträge filtern zu können. die zeile im error-log hat genau null Gehalt, da abgesehen von der IP nicht zu erkennen ist, was überhaupt angefragt wurde.

ich habe das Problem im zusammenhang mit einem Chat der per Ajax aktualisiert, also jede sekunde ein oder mehrere requests erzeugt, das ist im access-log schon unübersichtlich und muellt das error-log zusaetzlich zu, ohne das ich auf die schnelle erkennen kann, was genau er da eigentlich nicht laden kann.

der Apache unterstützt ja conditional logs ( siehe doc: http://httpd.apache.org/docs/2.2/logs.html ) - fein faende ich da, wenn lc dem customlog bzw. lclogsplit einen entsprechenden env-parameter mit uebergeben würde - zB das im apache-doc erwähnte tag 'dontlog' könnte man dann nutzen und jeder kann sich ggf. in die vhost-config entsprechende setenvif conditions einbinden, falls benötigt?!

Meiner Meinung nach sollte der 404-Fehler anders implementiert werden.

Wie wäre es damit (ungetestet):

RewriteRule ^$  /not-available.shtml [B] [R=404,L][/B]

Die Datei not-available.shtml existiert und es wird somit kein Log-Eintrag erzeugt. Gleichzeitig sendet der Webserver durch das Flag "R=404" den gewünschten 404-Fehler zurück.

Viele Grüße
Hendrik Obermayer

Top Vorschlag, getestet und für gut befunden! die Meldungs-Flut im error-log stoppt sofort und dem access-log ist zu entnehmen, das bei diesen anfragen weiterhin ein 404 gesendet wird... danke!
bin dafür, das dies standardmäßig von LC so gehandhabt wird, die Änderung ist minimal und dafür extra mit ner custom-lua rumzustricken, hmm...

ich halte trotzdem mal noch den vorschlag eines predefinierten env-flags für vom log auszunehmende dinge fest, das ist ja auch wenig änderungsaufwand und erzeugt, soweit es dann nicht explizit in eigenen vhosts verwendet wird, keine Änderung des bisherigen logging-verhaltens.

+1 eine sehr gute Lösung von comolo

+1 sehe ich auch so. Eine wunderbare Lösung.