Dateityp / Nime-Typ überschreiben

[Jörg Reinholz]

Einen unbekannten MIME-Type zu schicken, find ich ziemlich schmutzig.

Wer vertraut denn im Jahr 2013 noch auf einen im header gesendeten Dateityp?

IMO wäre es besser Content-Disposition entsprechend zu setzen.
»An opportunity to raise a "File Download" dialogue box for a known MIME type with binary format or suggest a filename for dynamic content. Quotes are necessary with special characters.«

Ja. Aber warum zeigst Du es nicht gleich?

if (is_file($filename) && is_readable($filename)) {
     header('Content-Type: ' . MIME_TYP);
     header("Content-Description: File Transfer");
     header("Content-Length: " . filesize($filename));
     header('Content-Disposition: attachment; filename="' . str_replace(dirname($filename), '', $filename) . '"');
     passthru($filename);
     exit;
} else ...

Für Variante 1 bzw 2 bräuchte man da wohl mod_headers.

Nein. Die ForceType-Direktive gehört  zum core, funktioniert im Apache ganz ohne Module. FilesMatch ebenso.

400 Bad Request ist wohl zutreffender.

Das kann man diskutieren, es ist aber ebenso zutreffend wie "nicht gefunden". Bad Request Method käme mit gleicher Berechtigung noch in Frage, ebenso wie 204 (No Content), 406 (Not Acceptable), 510 (Not Extended) käme sogar am nächsten.

Hier würde ich wohl auch noch mal unterscheiden, ob die Datei existiert (404 Not Found), oder ob der Server sie nicht lesen kann, aus welchm Grund auch immer (500 Internal Server Error)

Ich würde nicht zu viel verraten wollen. "Issnich" reicht meiner Meinung nach völlig aus, weil weitere Informationen ausschließlich Angreifern zu Gute kommen. Ich würde letztendlich sogar soweit gehen und bei einer evidenten(!) Häufung von Zugriffsversuchen auf Sachen WIE BEISPIELSWEISE '/etc/passwd', '/etc/shadow', '../*' sogar den Client aussperren. Das wäre aber wieder ein komplexe Sache, denn hier muss mit einigem Feingefühl vorgegangen werden, weil auch jemand bewusst solche Links bauen kann wodurch dann z.B. Suchmaschinen gesperrt werden würden.

(Verzeichnisse würde ich persönlich mit 400 Bad Request beantworten, es sei dann man will Archive des kompletten Verzeichnisses verschicken)

Archive kompletter Verzeichnisse zu versenden geht zwar auch dynamisch, davon würde ich aus Performancegründen aber absehen und eine Lösung vorziehen, bei der das Archiv im aufwendigsten Fall halbautomatisch erstellt und aktualisiert wird. Das geht sehr weit über die hier gestellte Frage hinaus und würde darauf hinauslaufen, dass ich
etwas wie ein ls -alr anwende,
die Rückgabe durch md5 jage, und dann mit dem Inhalt der gespeicherten Datei dir.md5 vergleiche

• Ist es gleich, dann
     -- sende ich die bestehende dir.tar.gz mit dem Content-Type "application/x-gzip"
• sonst
     -- lege ich die dir.md5 und das Archiv neu an und jage das Archiv durchs Äther, dass auch Kupfer oder Glas sein kann.

Jörg Reinholz