Dateityp / Nime-Typ überschreiben

[bubble]

Einen unbekannten MIME-Type zu schicken, find ich ziemlich schmutzig.
Wer vertraut denn im Jahr 2013 noch auf einen im header gesendeten Dateityp?

Ich vertraue zumindest auf header die ich selbst gesetzt hab :D

IMO wäre es besser Content-Disposition entsprechend zu setzen.
Ja. Aber warum zeigst Du es nicht gleich?

Daran hab ich einfach in dem Moment nicht gedacht.

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.

Das war auch Content-Disposition bezogen. Wenn man den header setzten will brauch man mod_headers

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.

204 passt mMn. nicht, da die Anfrage ja nicht erfolgreich war, 406 versteh ich so, dass es nur zu verwenden ist, wenn Accept-*-Bedingungen nicht erfüllt werden können. 510: Im verlinkten RFC trägts den Namen »An HTTP Extension Framework«, also um HTTP zu erweitern. Hier wird doch aber HTTP einfach nur "verwendet".

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 dachte daran, falls die Datei vorhanden ist und normalerweise lesbar ist (und eine erlaubte Datei repräsentiert), aber z.B. wegen eines temporären Locks oder der gleichen mit 500 zu antworten, und natürlich keine weiteren Informationen angeben.
Ich denke es macht auch für einen Anwender einen Unterschied, ob er ein 404 oder 500 vor gesetzt bekommt.

(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.

Das mit den Archiven war mehr oder weniger nur eine Randbemerkung, dass man die nicht die ganze Zeit on-the-fly generieren sollte, war mir schon bewusst. (Nebenbei, kann es sein, dass du ls -alR meintest? Oder gibt es einen bestimmten Grund, warum die Liste umgedreht sein soll?)

MfG
bubble