nicht angemeldet
Hallo dedlfix,
...sondern dass bei einem derart gesetzten expliziten Handler alle mit ...Type gesetzten MIME-Types ignoriert werden.
Nein. In der Verarbeitungskette der Handler, die ich schon mal kurz skizzierte, sitzt mod_header ganz am Anfang (Umformung der Requestheader) und ganz am Ende (Setzen der Responseheader).
Durch einen solche MIME-Type-Konfiguration versprach sich suit, den Content-Type der Response zu beeinflussen. Jedoch wird mit dem MIME-Type (oder file type, wie es die Handler-Dokumentationsseite bezeichnet) in erster Linie Apache-intern der Weg zum impliziten Handler geebnet. Und auch ob dieser den Content-Type aus dem MIME-Type/file type ableitet oder was eigenes macht ist, war nicht mit Apache-Direktiven beeinflussbar.
Das ist hier suit eigentliches Problem, die Verschränkung des apacheintern als Handler-Weiche genutzten Dateitypen mit dem Mediatypen, der auch in einem HTTP-Header mündet, gleichzusetzen. Daher ist das Setzten des Headers mittels mod_header, weil dies eben unabhängig vom Dateitypen geschieht, exakt am zu behebendem Symptom.
Und nun kommst du und warfst "Header set" ins Spiel. Ich bin momentan etwas irritiert, denn jetzt, bei einem erneuten Test, überschreibt es bei mir den Header. Leider weiß ich nicht mehr, was ich vorhin gemacht habe (ich sollte mir alle Versuche aufheben), denn da trat der Effekt ein, den ich schon die ganze Zeit beobachte, seit ich das Problem untersuche: Wenn ein Handler explizit konfiguriert war, hatte allein der das Sagen.
Offensichtlich ist etwas Theorie zu Webservern und den internen Vorgängen allgemein hier im Forum von Nöten, wie ältere Beispiele zeigen. (Ich werbe - äh - warne mal gleich vor: Seminare sind nicht billig. ;)
P.S. Möglicherweise war es beim ersten Test ein 304-Not Modified, das mich Glauben machte, Header zeige keine Wirkung. Das lief mir nämlich gerade im livehttpheaders-Tab über den Weg,...
Ich empfehle hier den HttpFox.
Gruß aus Berlin!
eddi