Es ist nicht ganz einfach Informationen zu finden, wie man bei Typo3 zu korrekten Fehlerseiten kommt, die auch einen 404er Fehlercode zurückliefern, vor allem wenn man mit simulatestatic arbeitet. Untersuchen kann man den gelieferten Fehlercode übrigens recht einfach mit der Firefox-Extension Firebug. In der Rubrik Netzwerk wird dort bei einem Seitenaufruf auch der Statuscode mit angezeigt.

Es gibt bei Typo3-Seiten eigentlich zwei unterschiedliche Situationen:

1. Typo3 wird direkt (/index.php?id=000) oder indirekt (/000.html) mit einer illegalen id aufgerufen
2. Die Domain wird mit einer URL aufgerufen, die nicht zur Typo3-Installation passt, z.B. mit einem Unterverzeichnis (/mediawiki/..)

Der erste Fall ist relativ einfach zu regeln, man erstellt in Typo3 eine Fehlerseite (hier fehler404.html) und erweitert die Konfigurationsdatei typo3conf/localconf.php folgendermaßen:

[FE][pageNotFound_handling] = /fehler404.html
[FE][pageNotFound_handling_statheader] = HTTP/1.0 404 Not Found

Damit wird für den Fall einer illegalen id die Fehlerseite aufgerufen und ein 404er Fehlercode zurückgeliefert.

Bleibt noch der zweite Fall. Typo3 würde in der Regel die Startseite liefern, egal was aufgerufen wurde. War in der aufgerufenen URL ein Unterverzeichnis angegeben, so wird das in dem Sinne berücksichtigt, dass Typo3 das Stylesheet nicht mehr findet. Die ausgelieferte Seite sieht also ganz komisch aus.

Um das zu ändern muss man an die Datei .htaccess ran, die man für simulatestatic ja aktivieren musste. Hier die .htacess, so wie sie von Typo3 geliefert wurde, ich habe alle Kommentarzeilen entfernt. Verändert habe ich lediglich die vorletzte Zeile:

<FilesMatch "\.(js|css)$">
  <IfModule mod_expires.c>
    ExpiresActive on
    ExpiresDefault "access plus 7 days"
  </IfModule>
  FileETag MTime Size
</FilesMatch>

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)\.(\d+)\.(php|js|css|png|jpg|gif|gzip)$ $1.$3 [L]

RewriteRule ^(typo3/|t3lib/|fileadmin/|typo3conf/|typo3temp/|uploads/|favicon\.ico) - [L]

RewriteRule ^typo3$ typo3/index_re.php [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule .* index.php?id=000 [L]

</IfModule>

In vielen Versionen der Datei werden nur Dateien mit der Endung .html ersetzt (RewriteRule ^[^/]*\.html$ index.php), hier wird jetzt immer die index.php aufgerufen, wenn die ursprüngliche Datei nicht gefunden wurde. Die index.php wird aber mit einer illegalen id aufgerufen, so dass ein Fehler nach Punkt 1 erzeugt wird. Typo3 wertet die übergebene id als String aus und nicht numerisch, eine id 000 wird es als sicherlich nicht geben, da beim Erzeugen einer Seite die id numerisch festgelegt wird. Die Idee dazu stammt von http://typo3.toaster-schwerin.de/typo3_dev/2008_04/msg00492.html.

Sofern die ursprünglich aufgerufenen id gültig war, spielt diese fehlerhafte id keine Rolle. Eine Erklärung dafür habe ich nicht, eventuell hat das etwas mit der Auswertungsreihenfolge von GET/POST Daten zu tun. Von daher ist nicht sichergestellt, dass dieser Trick auch in zukünftigen Typo3-Versionen funktioniert.

Ein Problem gibt es aber, wenn ein Slash (/) im Dateinamen auftaucht, dann gibt es zwar einen korrekten 404er Returncode, aber eine nackte Fehlerseite, da wieder das CSS nicht gefunden wird.

Mit

RewriteRule ^[^/]*\.html$ index.php [L]

stattdessen werden nur Adresse ohne Slash (/) ersetzt, bei anderen Adressen wird die Fehlerseite des Apache gezeigt, mit korrektem Fehlercode. Nun gibt es zwei unterschiedliche Fehlerseiten, einerseits die in Typo3, andererseits die vom Webserver. In beiden Fällen wird aber ein korrekter Fehlercode geliefert.