Schon öfters standen wir vor dem Problem, dass TYPO3 irgendwelche HTTP-Header liefert, nur nicht die, die wir erwarteten. Heute bin ich auf die Spur gestoßen: bei einem Kunden blieben gelöschte Seiten im Index der Suchengine. Ursache war, dass bei gelöschten Seiten eine Defaultseite mit aktuellem Inhalt gezeigt wurde – nur wurde dabei kein 404 odgl. gesendet, sondern ein „302 Found“, wodurch die veraltete URL dem indexer als in Ordnung suggeriert wurde. Das brachte aber die indizierten Inhalte durcheinandern.

In TYPO3 geguckt

Header werden elegant via API gesetzt mittels der Klasse t3lib_utility_Http (bzw. genamespacte Variante). Dort sind die Status auch als Konstanten deklariert wie zB. „const HTTP_STATUS_404 = ‚HTTP/1.1 404 Not Found‘;“. Dennoch bekommt man nach einem setResponseCode() keinen 404 raus… Auf der Suche nach einem händischen Weg an der API vorbei (Ja, auch ich tu sowas, wenn es dem Kunden nützt) stieß ich auf die Begründung:

Wenn FastCGI verwendet wird, muss folgendes benutzt werden um einen 404 Response Header zu senden:
 <?php
 header("Status: 404 Not Found");
 ?>

(http://php.net/manual/de/function.header.php)

Und siehe da, wenn man ohne die Konstante arbeitet, dann klappt’s auch mit der API:

t3lib_utility_Http::setResponseCode('Status: 404 Not Found');

Weitere Tests

Schon genug gesehen? Nein. Betrachten wir das Ganze nochmal genauer mit vier Testdateien und schauen mit Live HTTP headers die Antworten an:

test_1.php

<?php
header("HTTP/1.1 404 Not Found");
echo 'Sending "HTTP/1.1 404 Not Found"';
?>

Ergebnis:

test_2.php

<?php
header("HTTP/1.0 404 Not Found");
echo 'Sending "HTTP/1.0 404 Not Found"';
?>

Ergebnis:

test_3.php

<?php
header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found");
echo 'Sending "' . $_SERVER["SERVER_PROTOCOL"]. ' 404 Not Found"';
?>

Ergebnis:

test_4.php

<?php
header("Status: 404 Not Found");
echo 'Sending "Status: 404 Not Found"';
?>

Ergebnis:

Lösung?

Wer kennt eine Lösung?

Install-Tool: pageNotFound_handling_statheader

Um zumindest beim pageNotFound-Handling einen zur Umgebung passenden Header zu senden, kann/sollte im Install-Tool der passende Wert eingetragen werden:

realURL

Auch realURL hat ein paar Fallstricke dabei:

• appendMissingSlash
• realurl + appendMissingSlash + 404 notFound + 301 Moved permanently + SEO
• postVarSet_failureMode: Why RealURL sucks – and how to fix it (Folien 27+28) bzw. Korrektes 404 Error-Handling mit TYPO3
• deaktivieren von *.html