nicht angemeldet
suit
suit
suit
suit
suit
suit
Hallo,
ich hab' in meiner Apache-Config (2.2) - genauer gesagt in einer .htaccess-Datei - folgende Zeile hinzugefügt um Apache beizubringen, CSS-Files als PHP zu interpretieren:
AddHandler php5-script .css
Funktioniert soweit auch ganz gut, einziger Haken: ich muss nun per Hand in jeder CSS-Datei <?php header('content-type: text/css'); ?> notieren, damit die dinger wieder als text/css ausgeliefert werden (und nicht als text/html).
Nun habe ich versucht, mit
AddType text/css .css
Versucht, die betreffenden Ressourcen wieder als text/css ausliefern zu lassen - das "funzt" aber nicht.
Kann ich überhaupt nachträglich die MIME-Type ändern, wenn dieser schon an anderer Stelle gesetzt wurde.
Ich hab's bereits mit ForceType versucht, kein Effekt. RemoveType und danach erst AddType ebenfalls.
Wie ist hier die richtige Herangehensweise?
Wie ist hier die richtige Herangehensweise?
Ich würde eine PHP-Datei aufrufen und durch diese Datei das CSS ausgeben lassen mit dem passenden Content-Type.
Der Vorteil ist, dass nicht jede CSS-Datei durch den Parser läuft sondern nur die mit der Endung .php
Wenn jede css-Datei geparst wird, verschenkst du Rechenleistung und Geschwindigkeit bei normalen CSS-Dateien.
Ich würde eine PHP-Datei aufrufen und durch diese Datei das CSS ausgeben lassen mit dem passenden Content-Type.
Das ist die Notlösung Alternative, gefällt mir aber nicht da es sich um eine "tiefgreifende" Änderung handelt die auch sehr viele Dateien betrifft die einfach .css als Endung haben und deren Ressourcennamen ich nicht Ändern will, wenn es nicht unbedingt notwendig ist (Punkt).
Zudem soll dies aktuell den ersten Schritt darstellen und einfach nur ein paar @import-Regeln gegen geeignete readfile-Aufrufe ersetzen um die anzahl der HTTP-Requests zu minimieren.
Der Vorteil ist, dass nicht jede CSS-Datei durch den Parser läuft sondern nur die mit der Endung .php
Cool URIS don't change - es geht hierbei auch um CSS-Dateien die von Plugins oder Extensions eingefügt werden, auf die ich keinen Einfluss habe - siehe oben, die heissen nunmal so wie sie heissen, sollen aber auch aus verschiedenen Gründen durch den PHP-Interpreter.
Wenn jede css-Datei geparst wird, verschenkst du Rechenleistung und Geschwindigkeit bei normalen CSS-Dateien.
Wurde ausreichend getestet, gegen Null tendierenden Zeitverluste beim interpretieren werden allemal durch sehr viel Zeitgewinn beim Einsparen einiger HTTP-Requests aufgewogen.
Moin!
Wurde ausreichend getestet, gegen Null tendierenden Zeitverluste beim interpretieren
Das sieht anders aus, wenn PHP mal nicht mehr als Modul läuft. Dann wird es nämlich jedesmal geladen und gestartet. Insofern würde ich an Deiner Stelle tatsächlich dazu neigen mit mod_rewrite nur bestimmte css-Dateien gegen eine php-Datei zu mappen. Hinzu tritt: diese Vorgehensweise behebt Dein Problem.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
[...] Insofern würde ich an Deiner Stelle tatsächlich dazu neigen mit mod_rewrite nur bestimmte css-Dateien gegen eine php-Datei zu mappen. Hinzu tritt: diese Vorgehensweise behebt Dein Problem.
Das ist organisatorisch nicht ohne weiteres möglich da ich Großteils weder die Namen noch den Inhalt der CSS-Dateien kenne bzw. sich diese (Pfade) ändern können. Dazu müsste ich auf das Script umschreiben, das Script muss dann den Pfad zerlegen, das betreffende CSS lesen, sein Ding durchziehen und dann ausliefern.
Ist eine Möglichkeit, darüber muss ich nachdenken und das entsprechend Testen - scheint mir aber augenscheinlich aufwändiger zu sein.
Eine möglichgleich bietet sich aber mit "auto_prepend_file" - ich könnte jeder PHP-Datei einen Codeschnipsel voranstellen indem $_SERVER['SCRIPT_NAME'] betrachtet wird - wenn hinten .css steht, wird gibts eine entsprechende header()-Funktion. Muss ich ebenfalls testen.
Moin!
Eine möglichgleich bietet sich aber mit "auto_prepend_file" - ich könnte jeder PHP-Datei einen Codeschnipsel voranstellen indem
$_SERVER['SCRIPT_NAME']betrachtet wird - wenn hinten .css steht, wird gibts eine entsprechende header()-Funktion. Muss ich ebenfalls testen.
siehe: https://forum.selfhtml.org/?t=194268&m=1299252
das kannst Du da mit einbauen:
<FilesMatch ".(css|CSS)$">
php_value default_mimetype text/css
php_value auto_prepend_file .....
php_value auto_append_file ......
</FilesMatch>
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Moin!
AddHandler php5-script .css
Wozu? Warum gibst Du nicht <style type="text/css" >
Funktioniert soweit auch ganz gut, einziger Haken: ich muss nun per Hand in jeder CSS-Datei
<?php header('content-type: text/css'); ?>notieren, damit die dinger wieder als text/css ausgeliefert werden (und nicht als text/html).Nun habe ich versucht, mit
AddType text/css .css
Wie ist hier die richtige Herangehensweise?
Der Server glaubt PHP den Mime-Typ oder, wenn keiner gesendet wird, legt er ihn fest. Standart ist Text/Html.
Entweder Du setzt ihn mit
<?php header('content-type: text/css'); ?>
oder Du versuchst es mit einer ini-Direktive:
http://www.php.net/manual/de/ini.core.php#ini.default-mimetype
default_mimetype=text/css
dazu kannst Du eine php.ini im Verzeichnis ablegen.
oder, wenn PHP als Modul ausgeführt wird in einer Datei .htaccess die Werte setzen
php_value default_mimetype text/css
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
AddHandler php5-script .css
Wozu? Warum gibst Du nicht <style type="text/css" >
Ich kann dir nicht folgen.
Der Server glaubt PHP den Mime-Typ oder, wenn keiner gesendet wird, legt er ihn fest. Standart ist Text/Html.
Sprich PHP sind die MIME-Typen von Apache ansich egal bzw. er ignoriert sie und dreht sein eigenes Ding?
Entweder Du setzt ihn mit
<?php header('content-type: text/css'); ?>
Ja, habe ich - ist aber aus genannten Gründen nicht praktikabel, weil ich nicht jede Datei angreifen möchte.
default_mimetype=text/css
Das sorgt aber dafür das auch Dinge, die sich auf den default text/html verlassen falsch rausgeballert werden.
Moin!
AddHandler php5-script .css
Wozu? Warum gibst Du nicht <style type="text/css" >
Ich kann dir nicht folgen.
Ja. Ich hatte <link rel="stylesheet" type="text/css" href="/css/style0815.php" />
noch nicht ergänzt als ich entdeckte, dass Du Gründe hast.
Der Server glaubt PHP den Mime-Typ oder, wenn keiner gesendet wird, legt er ihn fest. Standart ist Text/Html.
Sprich PHP sind die MIME-Typen von Apache ansich egal bzw. er ignoriert sie und dreht sein eigenes Ding?
Ich korrigiere erst mal das Standart zu Standard. Ist keine stehende Kunst.
Die korrekte Reihenfolge ist:
Der Apache bekommt den Auftrag was auszuliefern:
-> "Huch ist ja PHP!"
--> PHP starten oder Modul füttern
---> PHP versucht einen Content-Typ in der php.ini (auch im Verzeichnis!) oder der Umgebung (auch mit .htaccess zu setzen) zu finden.
----> Der wird eventuell durch header('Content-type... im Skript überschrieben.
-----> Rückgabe der Ausgaben mit Content-Type an den Server.
Der Apache schaut jetzt nach: Bekam ich einen Content-Type gesendet?
-- Wenn ja-> Übernahme und aussenden.
-- Wenn nicht -> default aus der httpd.conf (und deren includes) oder htaccess.
default_mimetype=text/css
Das sorgt aber dafür das auch Dinge, die sich auf den default text/html verlassen falsch rausgeballert werden.
Nicht, wenn es in einer php.ini oder .htaccess in einem Verzeichnis gesetzt wird, in dem nur css-Dateien sind.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Nicht, wenn es in einer php.ini oder .htaccess in einem Verzeichnis gesetzt wird, in dem nur css-Dateien sind.
Definiere "gesetzt" - sprich wie soll ich ihn setzen? mit AddType gehts ja scheinbar nicht - auch mit <Files *.css> und ForceType hatte ich keinen Erfolg.
Moin!
Definiere "gesetzt" - sprich wie soll ich ihn setzen?
Per htaccess oder php.ini in den Verzeichnissen und für die Verzeichnisse , in denen die css-Dateien sind.
http://forum.de.selfhtml.org/my/?t=194268&m=1298722
Das hängt sehr davon ab, ob PHP als als Modul oder CGI ausgeführt wird. Eventuell ist es hilfreich, die bei php.net die entsprechenden Abschnitte nachzulesen.
AddType gehts ja scheinbar nicht - auch mit <Files *.css> und ForceType
Das kann keinen Einfluss haben, weil der Apache das nur beachtet, wenn das Modul oder CGI keinen Content-type-header sendet. Und PHP sendet das, was in der php.ini drin steht, also "text/html". Der Indianer glaubt das einfach, weil das Modul oder das CGI das ja besser wissen müssen. Also musst Du PHP (mit einer lokalen php.ini) oder einem Befehl, der es in die Umgebung schreibt (lokale .htaccess) dazu ermuntern die Einstellung aus der zentralen php.ini zu überladen (zu überschreiben).
Definitive Lösung für PHP als Modul:
Die test.css enthält, da sie nur als Beispiel dient und der Inhalt nicht interessiert, nur eine "1".
Die .htaccess hat folgenden Inhalt:
php_value default_mimetype text/css
AddHandler php5-script .css
Beweis durch Testabruf:
wget -d http://localhost/test4/test.css
DEBUG output created by Wget 1.11.1 on linux-gnu.
--2010-01-13 20:51:59-- http://localhost/test4/test.css
Auflösen des Hostnamen »localhost«.... 127.0.0.1, ::1
Caching localhost => 127.0.0.1 ::1
Verbindungsaufbau zu localhost|127.0.0.1|:80... verbunden.
Created socket 3.
Releasing 0x000000000064c430 (new refcount 1).
---request begin---
GET /test4/test.css HTTP/1.0
User-Agent: Mozilla 4.0 (Firefox 3.08)
Accept: */*
Host: localhost
Connection: Keep-Alive
---request end---
HTTP Anforderung gesendet, warte auf Antwort...
---response begin---
HTTP/1.1 200 OK
Date: Wed, 13 Jan 2010 19:51:59 GMT
Server: Apache/2.2.8 (Linux/SUSE)
X-Powered-By: PHP/5.2.11
Content-Length: 3
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/css # BINGO!
Du musst also nur die .htaccess in jedes Verzeichnis mit CSS-Dateien setzen.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Moin!
Das geht selbsterverständlich auch mit einer Datei test.css die folgendes (oder beliebiges anderen Php-Code enthält:
<?php echo 1; ?>
Zurückgeliefert wird zuverlässig die 1 und das Dateiende. PHP wird also auch ausgeführt. Nur falls das jemand bezweifeln möchte...
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Hallo,
Definitive Lösung für PHP als Modul:
[...]
ein vom SAPI PHPs unabhängige Lösung ist hier die Nutzung von auto_append_file. Das vorab einbezogene Script kann hierbei sogar die Umschreibung bezüglich der angesprochenen @import-Anweisungen der tatsächlichen CSS-Dateien übernehmen, ohne das diese PHP-Code überhaupt enthalten müssen. IMHO ist so auch vorzugehen, weil gerade dadurch CSS wie gewohnt und ohne Verschränkungen durch PHP entwickelt werden kann, während PHP nur durch Konfiguration quasi hinzugeschaltet wird, um die aus vielen Ressourcen eine zu formen.
Gruß aus Berlin!
eddi
Du musst also nur die .htaccess in jedes Verzeichnis mit CSS-Dateien setzen.
Und das soll mir Vorteile bringen? :)
Ich weiß ja nicht, wo überall css-Files liegen und wo welche dazukommen können.
Moin!
Du musst also nur die .htaccess in jedes Verzeichnis mit CSS-Dateien setzen.
Und das soll mir Vorteile bringen? :)
Ich weiß ja nicht, wo überall css-Files liegen und wo welche dazukommen können.
Dann mach es einfach im Hauptverzeichnis der betreffenden Domain oder schon direkt in deren Konfiguration...
.htaccess:
AddHandler php5-script .css .CSS
<FilesMatch ".(css|CSS)$">
php_value default_mimetype text/css
</FilesMatch>
... Ich will Dir aber nicht verheimlichen, dass ich das insgesamt für ziemlich üblen Murks halte. Wer soll das später (Jahre später...) mal pflegen, wenn in '.css'-Dateien (wo das keine Sau erwartet) Php-Code versteckt ist, der ggf. auch an spätere Wünsche angepasst werden muss?
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
AddHandler php5-script .css .CSS
<FilesMatch ".(css|CSS)$">
php_value default_mimetype text/css
</FilesMatch>
funzt™
<FilesMatch ".(css|CSS)$">
php_value default_mimetype text/css
</FilesMatch>
btw: ich konnte das in der Apache-Doku nicht finden - ist der Reguläre Ausdruck in den Match-Abschnitten case-sensitive oder nicht - bzw. wo füge ich im zweifelsfall Modifikatoren an? Sollte da ".(?i)css$" nicht auch ausreichen?
Hallo,
Nicht, wenn es in einer php.ini oder .htaccess in einem Verzeichnis gesetzt wird, in dem nur css-Dateien sind.
Definiere "gesetzt" - sprich wie soll ich ihn setzen? mit AddType gehts ja scheinbar nicht - auch mit <Files *.css> und ForceType hatte ich keinen Erfolg.
Direktiven AddType und ForceType bestimmen bei Request-Verarbeitung den Dateitypen. Dieser Dateityp ist allermeist identisch mit dem MIME- (oder auch benannt als) Mediatyp. Mittels ihm werden durch den Apachen unterschiedliche Handler aufgerufen; bspw.: ForceType application/x-httpd-php -> Handler PHP wird gestartet. Dies, wie gesagt, und jetzt nochmals geschrieben, hat mit der Request-Verarbeitung zu tun, denn PHP wird nicht an den Browser mit Mediatyp application/x-httpd-php ausgeliefert.
Aus dem Dateitypen wird, nachdem alle Handler des Apachen den Request verarbeitet haben und die Ressource zum versenden bereitsteht, der Mediatyp, der Wert im HTTP-Header Content-Type. Überschreibt ein Handler den Dateitypen (header('Content-Type: text/css'); als PHP-Beispiel), wird dieser also auch als Content-Type-Wert ausgegeben. Wichtig ist also zu verstehen, dass AddType und ForceType genutzt werden, um die entsprechenden Handler (z. B. PHP) für den Request zu aktivieren, während das Stetzen von Content-Type-Headern in den Handlern (was ja auch ein Perl-Script sein kann) die Angaben dieser Apache-Konfigurationsdirektiven überschreibt und _letztendlich_ zum Mediatypen wird.
Gruß aus Berlin!
eddi
Hallo,
Der Server glaubt PHP den Mime-Typ oder, wenn keiner gesendet wird, legt er ihn fest. Standart ist Text/Html.
Direktive DefaultType ist dafür verantwortlich. Default (also unkonfiguriert) ist das text/plain.
Gruß aus Berlin!
eddi
Kann ich überhaupt nachträglich die MIME-Type ändern, wenn dieser schon an anderer Stelle gesetzt wurde.
Eigentlich schon!
Man möge mich als Perl-Jünger eines besseren belehren, aber genau da vermute ich dennoch das Problem. Allerdings nicht seitens des Apachen, sondern PHP. Gibt man keinen expliziten Content-Type an, dann macht PHP das automatisch, richtig?
Das "sieht" der Apache dann als manuellen Override und lässt "seine" Finger davon.
Wie ist hier die richtige Herangehensweise?
Machs umgekehrt. Rewrite der .css Ressource auf ein PHP Script. Da gibt es fertige Sachen inkl. Minifizierung:
Hi,
Kann ich überhaupt nachträglich die MIME-Type ändern, wenn dieser schon an anderer Stelle gesetzt wurde.
Eigentlich schon!
Man möge mich als Perl-Jünger eines besseren belehren, aber genau da vermute ich dennoch das Problem. Allerdings nicht seitens des Apachen, sondern PHP. Gibt man keinen expliziten Content-Type an, dann macht PHP das automatisch, richtig?
Ich kenne die urspr. Anfrage zwar nicht, aber richtig ist, das php den Header autom. setzt. Man kann ihn mit der Funktion header('Content-type: xxx'); selbst setzen. Hinweis: vor dem Aufruf von header() darf keine Ausgabe (echo etc.) stattfinden.
Das "sieht" der Apache dann als manuellen Override und lässt "seine" Finger davon.
Wie ist hier die richtige Herangehensweise?
Machs umgekehrt. Rewrite der .css Ressource auf ein PHP Script. Da gibt es fertige Sachen inkl. Minifizierung:
Moin!
Man möge mich als Perl-Jünger eines besseren belehren,
Nun, Perl macht es so viel anders nicht.
ohne: print "Content-type: text/html\n\n"; gibts sogar einen 500er, weil der Apache meint, er wisse nicht, was er für einen Content-type im Header senden soll.
Der wesentliche Unterschied ist, dass keiner auf die Idee kommt, css-Dateien durch den Perl-Interpreter zu jagen, weil der ja nicht nach einem <?perl ?> sucht. (Obwohl es durchaus mal Ansätze gab, auch ein <script language="perl">...</script> in HTML-Dateien zu verbauen und serverseitig zu parsen.)
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
ohne:
print "Content-type: text/html\n\n";gibts sogar einen 500er, weil der Apache meint, er wisse nicht, was er für einen Content-type im Header senden soll.
Stimmt, den 500er im CGI Kontext hatte ich nicht bedacht. Bin schon zu lange auf mod_perl. Aber selbst "auf CGI" hätte ich die Möglichkeit, einfach nur den Header per "\n\n" zu beenden und dann per "AddType text/html .pl" zu arbeiten.
Der wesentliche Unterschied ist, dass keiner auf die Idee kommt, css-Dateien durch den Perl-Interpreter zu jagen, weil der ja nicht nach einem <?perl ?> sucht. (Obwohl es durchaus mal Ansätze gab, auch ein <script language="perl">...</script> in HTML-Dateien zu verbauen und serverseitig zu parsen.)
Das nicht ausgezeichnete Bereiche in PHP durchgereicht werden, ist eine unbestritten essentielle Grundlage für suits Ansatz...
Hallo,
ohne:
print "Content-type: text/html\n\n";gibts sogar einen 500er, weil der Apache meint, er wisse nicht, was er für einen Content-type im Header senden soll.
was den HTTP-Status 500 betrifft, ist die Beobachtung zwar richtig; die Schlussfolgerung ist es jedoch nicht. Apache sendet nicht deswegen den Status 500 weil kein Content-Type-Header angegeben sei. Es wird der CGI-Standart schlichtweg nicht eingehalten, der zwischen durch den Webserver zu sendenden HTTP-Headern, die das entsprechenden Script bestimmen kann und dem eigentlichen Inhalt kein Trenner ist. Der Inhalt, der vom Script an den Server zum Senden übergeben wird, wird folglich durch den Server versucht als HTTP-Header zu parsen. Dieses schlägt fehl, was zum Status 500 führt.
Beispiele:
#!/pfad/zu/perl
#
# -falsch-
print "Huhu."
#!/pfad/zu/perl
#
# -richtig-
print "Content-type: text/plain\n\n";
print "Huhu."
#!/pfad/zu/perl
#
# -auch richtig-
print "\r\n";
print "Huhu."
Der Trenner besteht also in einer leeren Zeile. Die Spezifikation schreibt dazu ein CRLF vor. Übrigens wird auch ein einfaches \n durch Perl zu CRLF als Trenner umgewandelt.
Gruß aus Berlin!
eddi
mod_rewrite und das T-Flag stellen hier eine Lösung bereit:
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriteflags
'type|T=MIME-type' (force MIME type)
Force the MIME-type of the target file to be MIME-type. This can be used to set up the content-type based on some conditions. For example, the following snippet allows .php files to be displayed by mod_php if they are called with the .phps extension:
RewriteRule ^(.+.php)s$ $1 [T=application/x-httpd-php-source]
Das Beispiel umgebaut auf css-Ressourcen (RewriteRule ^(.+.css)$ $1 [T=text/css]) funktioniert aber nicht.
https://issues.apache.org/bugzilla/show_bug.cgi?id=36590
Scheint aber genau das zu sein, was ich benötige - sobald aber der PHP-Interpreter das Sagen hat, greift diese Regel nicht mehr - nichtmal das Originalbeispiel aus der Dokumentation funktioniert :)
Mal sehen ob's etwas bringt, das direkt in die Apache-Config zu schreiben.
Hi!
Das Beispiel umgebaut auf css-Ressourcen (RewriteRule ^(.+.css)$ $1 [T=text/css]) funktioniert aber nicht.
Scheint aber genau das zu sein, was ich benötige - sobald aber der PHP-Interpreter das Sagen hat, greift diese Regel nicht mehr - nichtmal das Originalbeispiel aus der Dokumentation funktioniert :)
Meiner Meinung nach kann das ganze Vorhaben nicht gelingen. Die Bearbeitung des Requests wird an einen Handler weitergeleitet, hinter dem in deinem Fall PHP steckt. Der Apache gibt also das Zepter an einen Spezialisten ab und vertraut nun voll und ganz auf dessen Expertise, was das Ergebnis inklusive Content-Type angeht. Als Webserver-Programmierer würde ich mir auch nicht "anmaßen" wollen, deligierte Aufgaben zu korrigieren. Denn aus der anderen Richtung gesehen würde es mir als Handler-Verwender auch nicht gefallen, wenn der Apache dies täte. Jedenfalls müsste eine Handler-Ergebnis-Überschreibung bei der Konfiguration des Handlers angesiedelt sein und und dort zu finden sein, wenn es sie gäbe, und nicht bei der Mime-Type-Konfiguration für Ressouren, die sich aus fertigen Dateien ergeben.
Lo!
Meiner Meinung nach kann das ganze Vorhaben nicht gelingen.
Da ist die Apache-Doku aber anderer Meinung :) Die Doku entspricht nicht dem, was dort versprochen wird - nichtmal das Beispiel funktioniert (welches ja nicht wirklich praxisfern ist).
Hi!
Meiner Meinung nach kann das ganze Vorhaben nicht gelingen.
Da ist die Apache-Doku aber anderer Meinung :)
Ich denke, du interpretierst sie nur falsch.
Die Doku entspricht nicht dem, was dort versprochen wird - nichtmal das Beispiel funktioniert (welches ja nicht wirklich praxisfern ist).
Es geht dabei um Files, die ausgeliefert werden sollen, nicht um an Handler delegierte Requests.
Lo!
Hi!
Es geht dabei um Files, die ausgeliefert werden sollen, nicht um an Handler delegierte Requests.
Um mal das Beispiel auseinanderzunehmen:
RewriteRule ^(.+.php)s$ $1 [T=application/x-httpd-php-source]
Der Request nach *.phps wird umgeschrieben auf den apache-internen Mimetype application/x-httpd-php-source. Nach einem Rewrite-Vorgang wird der nun geänderte Request erneut ins Rennen geschickt und der Apache nimmt den Handler "PHP-Source-Code ausliefert, aber bitte schön bunt".
Du kannst das so nicht einsetzen, weil der Mime-Type text/css nicht an den PHP-Handler geht. Du willst ja erst den Handler ausführen und dann Content-Type ändern.
Lo!
Der Request nach *.phps wird umgeschrieben auf den apache-internen Mimetype application/x-httpd-php-source. Nach einem Rewrite-Vorgang wird der nun geänderte Request erneut ins Rennen geschickt und der Apache nimmt den Handler "PHP-Source-Code ausliefert, aber bitte schön bunt".
"Funzt nicht" - probiers aus, exakt diese Zeile aus der Dokumentation funktioniert nicht. example.com/index.phps sollte den Quelltext von index.php ausliefert - tuts aber nicht.
Du kannst das so nicht einsetzen, weil der Mime-Type text/css nicht an den PHP-Handler geht. Du willst ja erst den Handler ausführen und dann Content-Type ändern.
Natürlich.
Hi!
Der Request nach *.phps wird umgeschrieben auf den apache-internen Mimetype application/x-httpd-php-source. Nach einem Rewrite-Vorgang wird der nun geänderte Request erneut ins Rennen geschickt und der Apache nimmt den Handler "PHP-Source-Code ausliefert, aber bitte schön bunt".
"Funzt nicht" - probiers aus, exakt diese Zeile aus der Dokumentation funktioniert nicht. example.com/index.phps sollte den Quelltext von index.php ausliefert - tuts aber nicht.
Bei meinem Test "funzte" es so wie ich es erwartete. Vielleicht reagiert dein PHP auf andere MIME-Types als den angegebenen, einige Hoster konfigurieren das anders als vorgeschlagen. Es ist jedoch für deinen Fall irrelevant, ob das funktioniert oder nicht, weil es ganz einfach der falsche Ansatzpunkt ist, an dem du die ganze Zeit hantierst. Du hast mich nun soweit gebracht, dass ich verschiedene Dokumentation gesucht, gefunden und gelesen habe, wie der Apache intern arbeitet. Dafür bekommst dun nun eine Antwort, die du nicht haben willst :-), weil sie dein Problem nicht direkt weiterbringt, sie dir aber hoffentlich zeigt, dass du nicht weiterkommen kannst, so wie du es gerade versuchst.
Ein Webserver, so auch der Apache, arbeitet grob gesagt nach diesem Prinzip:
Request -> Content-Generator -> Response
Der Content-Generator ist verantwortlich, was als Response zurückgeht. Im einfachsten Fall ist das ein Dateiinhalt. Soweit sollte das ja bekannt sein. Beim Apachen fungieren die Handler als Content-Generator. Das Finden des passenden Handlers kann dabei einerseits direkt über eine Dateiendung oder eine Position im Filesystem erfolgen, andererseits indirekt über einen MIME-Type. Wenn also kein Handler direkt zugewiesen ist, muss erst ein Mapping auf einen MIME-Type erfolgen, damit dann ein dem MIME-Type zugewiesener Handler arbeiten kann.
Wenn du nun also schon auf direktem Wege zu einem Handler gelangt bist, ist die allgemeine MIME-Type-Konfiguration des Apachen nicht mehr wichtig, um den Content-Type zu bestimmen, sondern nur noch das was der Handler als Content-Type deklariert.
Beim indirekten Weg über einen MIME-Type (der ein offizieller oder auch nur ein intern verwendeter sein kann) bestimmt letztlich auch der Handler, was als Content-Type in der Response steht. Manchmal ist es der "unterwegs" ermittelte, der vom Handler durchgereicht wird, manchmal ein vom Handler generierter.
Das Content-Type-Ergebnis vom Handler ist also nur in ihm selbst beeinflussbar und nur beim durchreichenden Handler von der Apachen-MIME-Type-Konfiguration.
Lo!
Hi!
Nachtrag:
Das Content-Type-Ergebnis vom Handler ist also nur in ihm selbst beeinflussbar und nur beim durchreichenden Handler von der Apachen-MIME-Type-Konfiguration.
Hinzu kommt möglicherweise noch der von Pragma ins Rennen geworfene Filter, den ich bei dieser Gelegenheit zum ersten Mal wahrgenommen habe. Mir ist bisher noch kein konkreter Anwendungsfall zufällig im Web begegnet, aber wenn du auf diesem Wege weitermachen willst, so denke ich, wirst du ein Apache-Modul (oder wie auch immer man den Filter einbindet) schreiben müssen.
Lo!
Hi!
Ich bin heute sehr nachtragend. Hier noch einer:
"Funzt nicht" - probiers aus, exakt diese Zeile aus der Dokumentation funktioniert nicht. example.com/index.phps sollte den Quelltext von index.php ausliefert - tuts aber nicht.
Bei meinem Test "funzte" es so wie ich es erwartete.
Dazu muss ich sagen, dass ich auf die Schnelle ein HTML-Dokument mit dem T=text/plain umschreiben ließ, was zur textuellen Anzeige des HTML-Codes im Browser (!=IE) führte. Insofern arbeitet das Feature schon richtig. Dann setzte ich mir einen Xampp auf, und probierte das
RewriteRule ^(.+\.php)s$ $1 [T=application/x-httpd-php-source]
und siehe da, die PHP-Datei wurde ausgeführt und nicht als Quelltext ausgeliefert. Das RewriteLog schrieb jedoch brav (etwas gekürzt):
(2) [perdir C:/xampp/htdocs/] rewrite 'index.phps' -> 'index.php'
(2) [perdir C:/xampp/htdocs/] remember C:/xampp/htdocs/index.php to have MIME-type 'application/x-httpd-php-source'
(2) [perdir C:/xampp/htdocs/] strip document_root prefix: C:/xampp/htdocs/index.php -> /index.php
(1) [perdir C:/xampp/htdocs/] internal redirect with /index.php [INTERNAL REDIRECT]
(1) force filename redirect:/index.php to have MIME-type 'application/x-httpd-php-source'
(1) [perdir C:/xampp/htdocs/] pass through C:/xampp/htdocs/index.php
(1) [perdir C:/xampp/htdocs/] pass through C:/xampp/htdocs/index.php
(1) [perdir C:/xampp/htdocs/] pass through C:/xampp/htdocs/index.php
Nun erinnerte ich mich an die Sache mit den direkten Handlern und prüfte die Konfiguration
<FilesMatch "\.php$">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch "\.phps$">
SetHandler application/x-httpd-php-source
</FilesMatch>
Aha, die Handler werden direkt aufgrund der passenden FilesMatch-Bedingung verwendet und nicht über den MIME-Type. Aber auch obiges deaktiviert und umgeschrieben auf
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
brachte keine Änderung (natürlich mit Neustart des Apachen nach jeder Konfigurationsänderung). Ich vermute, da hat mod_php in dieser Hinsicht einen Bug. Das Sourcecode-Ausgeben an und für sich klappte nämlich auch.
Lo!
Ich vermute, da hat mod_php in dieser Hinsicht einen Bug. Das Sourcecode-Ausgeben an und für sich klappte nämlich auch.
Sagte ich doch schon: https://issues.apache.org/bugzilla/show_bug.cgi?id=36590
Hi!
Ich vermute, da hat mod_php in dieser Hinsicht einen Bug. Das Sourcecode-Ausgeben an und für sich klappte nämlich auch.
Sagte ich doch schon: https://issues.apache.org/bugzilla/show_bug.cgi?id=36590
Nee, ich sagte mod_php, du meintest aber mod_rewrite. Und wenn du grad den Bug wiedereröffnet hast, so liegst du da nicht richtig. Du willst du immer noch den von einem Handler definierten Content-Type umschreiben. Das wird definitiv nicht anderswo gehen als in diesem Handler selbst (oder in einem nachgelagerten Filter). In dem Bug ging es um die Ermittlung des MIME-Types von Dateien, die von einem Durchreich-Handler zu Response verarbeitet werden.
Ich hab noch weitere Tests zu dem Thema angestellt. Dieses Flag arbeitet, wie schon in dem Bericht erwähnt, nur dann richtig, wenn kein Umschreiben stattfindet. Schreibt man den Request um, geht dabei der MIME-Type verloren. Jeder umgeschriebene Requests erzeugt einen internen Redirect, der wie ein neuer Request behandelt wird. Außerdem darf kein Handler den Request auf direktem Wege verarbeiten, denn dann wird der MIME-Type ja gar nicht beachtet.
Beispiel 1:
RewriteRule ^(.+.php)$ - [T=application/x-httpd-php-source]
Veranlasst die Ausgabe des PHP-Codes in Farbe und bunt. Voraussetzung ist, dass für .php kein Handler definiert ist.
<FilesMatch .php$>
SetHandler application/x-httpd-php
</FilesMatch>
Solch ein Handler verhindert das Auswerten des MIME-Types, obwohl mod_rewrite arbeitet, was man im RewriteLog sehen kann.
AddType application/x-httpd-php .php
darf jedoch gesetzt sein, das wird durch die RewriteRule außer Kraft gesetzt.
Beispiel 2:
RewriteRule ^(.+.php)s$ $1 [T=application/x-httpd-php-source]
Obige RewriteRule steht so im Handbuch, und so funktioniert es definitiv nicht.
RewriteRule ^(.+).html$ $1.php
RewriteRule ^(.+).php$ - [T=application/x-httpd-php-source]
Das geht, aber wie gehabt unter der Voraussetzung, dass kein .php-Handler aktiv ist.
Der Content-Type der Response ist aber bei beiden Beispielen nicht etwa application/x-httpd-php-source - das wäre auch ziemlich sinnfrei - sondern text/html, weil der PHP-Handler diesen so festgelegt hat. Wenn man das Spielchen mit Durchreich-Typen wie .html oder .jpg probiert, dann ist der Content-Type gleich dem MIME-Type.
Lo!
Hallo suit,
Der Request nach *.phps wird umgeschrieben auf den apache-internen Mimetype application/x-httpd-php-source. Nach einem Rewrite-Vorgang wird der nun geänderte Request erneut ins Rennen geschickt und der Apache nimmt den Handler "PHP-Source-Code ausliefert, aber bitte schön bunt".
"Funzt nicht" - probiers aus, exakt diese Zeile aus der Dokumentation funktioniert nicht. example.com/index.phps sollte den Quelltext von index.php ausliefert - tuts aber nicht.
hast Du überhaupt für application/x-httpd-php-source einen Handler angelegt?
Gruß aus Berlin!
eddi
Analog meiner gestrigen sowie dedlfix heutiger Ausführung glaube ich nicht, dass du so zum Ziel kommst.
Filter _könnten_ dir weiterhelfen...
Aber soweit ich dich verstanden habe, sollen schlicht alles .css durch PHP gejagt werden, richtig? Warum dann nicht so:
RewriteRule ^(.+.css)$ /php/meinphpcssding.php?cssfile=$1
Wenn nicht: Warum nicht? ;-)
Filter _könnten_ dir weiterhelfen...
Muss ich mir ansehen :)
Aber soweit ich dich verstanden habe, sollen schlicht alles .css durch PHP gejagt werden, richtig? Warum dann nicht so:
RewriteRule ^(.+.css)$ /php/meinphpcssding.php?cssfile=$1
Warum nicht so? Das habe ich ja bereits angemerkt:
RewriteRule ^(.+.css)$ /meincssding.php [L]
Das ist etwas langsamer (unwesentlich) als die zuerst angedachte Variante, funktioniert aber nicht so einfach handhabbar, wie ich mir das eigentlich erwartet hätte.
Wenn nicht: Warum nicht? ;-)
Warum ursprünglich nicht? Ein @import durch ein readfile zu ersetzen ist in der AddHandler-Variante problemlos möglich - jetzt muss ich einen "Parser" schreiben, der das kann (und dabei noch CSS-Syntax versteht - Kommentare, Medientypen usw. :)
Ich habe wohl noch ein essentielles Verständnisproblem bei der ganzen Aktion. Wenn du dem Apachen per AddHandler css sagst, er solle .css Files durch den PHP Interpreter jagen, ist bis auf den falschen Content-Type alles supi, ja?
Wo ist dann das Problem bei der Rewrite Variante?
Da sehe ich derzeit einzig die zusätzliche Ermittlung des CSS Pfads - das sollte doch hinreichend trivial sein?!
Jede weitere "Intelligenz" musst du doch eh schreiben?
Wo ist dann das Problem bei der Rewrite Variante?
Dass ich die "Intelligenz" schreiben muss.
Da sehe ich derzeit einzig die zusätzliche Ermittlung des CSS Pfads - das sollte doch hinreichend trivial sein?!
Jein -
was tust du mit einem CSS, in welchem folgendes steht
/* @import url('foo.css'); */
h1 { color: red; }
@import url('bar.css');
Jede weitere "Intelligenz" musst du doch eh schreiben?
Nein, müsste ich nicht.
was tust du mit einem CSS, in welchem folgendes steht
/* @import url('foo.css'); */
h1 { color: red; }
@import url('bar.css');
Jetzt habe ich deinen Punkt verstanden, danke. Klar, dass könnte schnell sehr übel werden.
Ohne nun zu wissen, wie du die Magie "s/import url/readfile/g" per AddHandler anwendest: Wie kannst du sicher sein, dass das in jedem Falle hinhaut?
Mehrfach verschachtelte Kommentare(z.B. foo.css entählt /* .. */ ), wirre relative Pfadkonstrukte...
Da fehlt mir offensichtlich einiges an PHP / AddHandler Verständnis und so wiederhole nur nochmal meinen Tipp von gestern, das Teil arbeitet auch "import" ab:
http://code.google.com/p/minify/
Ohne nun zu wissen, wie du die Magie "s/import url/readfile/g" per AddHandler anwendest: Wie kannst du sicher sein, dass das in jedem Falle hinhaut?
Wenn ich das AddHandler händisch mache, steht es mir Frei im CSS file @import url('foo.css'); oder <?php readfile('foo.css'); ?> manuell zu notieren und ich muss nicht extra einen parser schreiben.
Da fehlt mir offensichtlich einiges an PHP / AddHandler Verständnis und so wiederhole nur nochmal meinen Tipp von gestern, das Teil arbeitet auch "import" ab:
http://code.google.com/p/minify/
Das hab ich gestern wohl überlesen, klingt sehr interessant.
Hallo
Nun habe ich versucht, mit
AddType text/css .css
Versucht, die betreffenden Ressourcen wieder als text/css ausliefern zu lassen - das "funzt" aber nicht.
Vielleicht habe ich den entsprechenden Loesungsvorschlag im Thread uebersehen, aber hast du mal probiert, den Content-Type header mit der Apache-Direktive Header zu setzen? Das folgende klappt zumindest auf meinem lokalen Xampp:
<FilesMatch "\.css$">
SetHandler application/x-httpd-php
Header set Content-Type text/css
</FilesMatch>
Viel Erfolg
Claudia
<FilesMatch ".css$">
SetHandler application/x-httpd-php
Header set Content-Type text/css
</FilesMatch>
Hat keinen Effekt - ebenso mit Files anstatt FilesMatch
Hi!
<FilesMatch ".css$">
SetHandler application/x-httpd-php
Header set Content-Type text/css
</FilesMatch>Hat keinen Effekt - ebenso mit Files anstatt FilesMatch
Genauer gesagt: Hat keinen Effekt bei direkten Handlern, nur MIME-Type-Handler sind betroffen.
Lo!
Hallo dedlfix
Genauer gesagt: Hat keinen Effekt bei direkten Handlern, nur MIME-Type-Handler sind betroffen.
Beziehst Du Dich damit auf AddHandler versus SetHandler? Aus der Apachedoku habe ich als Hauptunterschied nur herausgelesen, dass man AddHandler auf Dateien einen bestimmten Typs anwendet, waehrend SetHandler anscheinend vor allem dafuer geeignet ist, in einem <Location>- oder <Files>-Block verwendet zu werden. Aber anscheinend gibt es da ja doch bedeutsame Unterschiede in der Funktionsweise, wenn die Wahl zwischen Addhandler und SetHandler Auswirkungen auf die Header-Direktive hat. Koenntest Du mir die Unterschiede erklaeren oder mich auf eine (wenn moeglich auch fuer Laien verstaendliche) Erlaeuterung verweisen?
Herzlichen Dank
Claudia
Hi!
Genauer gesagt: Hat keinen Effekt bei direkten Handlern, nur MIME-Type-Handler sind betroffen.
Beziehst Du Dich damit auf AddHandler versus SetHandler?
Nein. Wie ich in meinen anderen Antworten schon ausführte, meine ich ich den Unterschied zwischen einem Handler, der direkt auf eine Dateiendung oder einen Ort konfiguriert wird und einen, der über den Umweg eines MIME-Types aktiv wird. Die verlinkte Dokumentationsseite spricht von explizitem und implizitem Handler. Vielleicht sollte ich meinen Sprachgebrauch dahingehend anpassen.
Aus der Apachedoku habe ich als Hauptunterschied nur herausgelesen, dass man AddHandler auf Dateien einen bestimmten Typs anwendet, waehrend SetHandler anscheinend vor allem dafuer geeignet ist, in einem <Location>- oder <Files>-Block verwendet zu werden.
AddHandler und SetHandler konfigurieren beide explizite Handler. AddHandler aufgrund der Dateiendung, SetHandler aufgrund eines Ortes (<Files>-Container zählen dazu)
Aber anscheinend gibt es da ja doch bedeutsame Unterschiede in der Funktionsweise, wenn die Wahl zwischen Addhandler und SetHandler Auswirkungen auf die Header-Direktive hat.
Nicht zwischen den beiden, sondern grob gesagt zwischen ...Handler und ...Type.
Lo!
Hallo dedlfix,
danke fuer die ausfuehrliche Antwort. Leider muss ich gestehen, dass ich anscheinend entweder diese Antwort oder deine vorige Antwort nicht richtig verstehe.
AddHandler und SetHandler konfigurieren beide explizite Handler.
Der Originalposter hatte AddHandler verwendet, ich SetHandler, was also beides explizite/direkte Handlerzuweisungen sind. Bei mir (Apache 2.2.12) funktioniert die Zuweisung eines Content-Type-Headers mittels Header set jedoch, beim Originalposter anscheinend aber nicht. Also kann das doch nicht am Unterschied zwischen expliziten/impliziten Handlern liegen, oder?
Abgesehen davon verstehe ich auch nicht, wieso die Zuweisung eines Handlers Auswirkungen auf die Header-Direktive haben sollte - letzten Endes weist man Apache doch einfach nur an, bei alles Dateien, die eine bestimmte Endung haben, einen bestimmten Header mitzuschicken. Solange dieser Header nicht von einer anderen Direktive ueberschrieben wird, muesste das doch immer klappen?
Claudia
Hi!
AddHandler und SetHandler konfigurieren beide explizite Handler.
Der Originalposter hatte AddHandler verwendet, ich SetHandler, was also beides explizite/direkte Handlerzuweisungen sind.
Der Unterschied zwischen AddHandler und SetHandler ist meiner Meinung nach nicht das Problem, sondern dass bei einem derart gesetzten expliziten Handler alle mit ...Type gesetzten MIME-Types ignoriert werden. Sie sind ja auch nicht mehr nötig, wenn ein Handler anderweitig gefunden werden konnte. 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.
Bei mir (Apache 2.2.12) funktioniert die Zuweisung eines Content-Type-Headers mittels Header set jedoch, beim Originalposter anscheinend aber nicht. Also kann das doch nicht am Unterschied zwischen expliziten/impliziten Handlern liegen, oder?
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.
Es sieht also derzeit so aus, dass "Header set" doch die Macht hat, implizite und explizite Handler-Ergebnisse zu beeinflussen.
Abgesehen davon verstehe ich auch nicht, wieso die Zuweisung eines Handlers Auswirkungen auf die Header-Direktive haben sollte - letzten Endes weist man Apache doch einfach nur an, bei alles Dateien, die eine bestimmte Endung haben, einen bestimmten Header mitzuschicken. Solange dieser Header nicht von einer anderen Direktive ueberschrieben wird, muesste das doch immer klappen?
So ist der Plan. Und bis eben war uns™ offensichtlich keine solche überschreibende Direktive bekannt. Alle (außer den ominösen Filtern) befassten sich mit dem Weg zum Content Generator/Handler und nicht mit dem Ändern seines Ergebnisses.
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, als ich mit
Header set Content-Type text/plain
in einer .htaccess unter anderem eine Bilddatei als Plaintext ausgeben wollte, die vorher schon ein Opfer eines anderen Tests wurde.
Lo!
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
Hi!
...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).
Wieso "nein"? Von den HTTP-Headern hab ich doch hier gar nicht gesprochen, sondern vom file type zum Finden des Handlers. Und warum soll der dafür noch gebraucht werden, wenn der Handler schon explizit bestimmt worden ist?
Ich empfehle hier den HttpFox.
Der kann mich nicht als Ersatz überzeugen. Er bietet auch nicht mehr Information als livehttpheaders, nur dass er sie anders aufbereitet. Desweiteren integriert er sich nicht im Kontextmenüpunkt "Seiteinformation anzeigen". Bei der lhh kann ich dort im Nachhinein sehen, welche Header zumindest für die aktuelle Seite gesendet worden. Der HttpFox muss dazu vor dem Request explizit gestartet worden sein.
Lo!
Re:
...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).Wieso "nein"?
Wird beispielsweise kein Content-Header vom Handler gesetzt, wird dieser z. B. durch AddTpye bestimmt. Allerdings sehe ich auch jetzt etwas besser als heute in der Frühe, worum es Dir tatsächlich ging. In dem Sinne, explizit Handler außerhalb des Dateitypen zu setzen, hast Du auch Recht.
Gruß aus Berlin!
eddi
Hi!
Offensichtlich ist etwas Theorie zu Webservern und den internen Vorgängen allgemein hier im Forum von Nöten
Dann möchte ich mal anfangen und mein Verständnis von der internen Arbeitsweise zusammenfassen. Dabei will ich nicht jeden Aspekt aufführen, sondern nur die für suits Problem relevanten. Filter lass ich ebenfalls weg, weil ich sie als praktisch wenig relevant einschätze. Eddi, du hilfst mir doch sicherlich, wenn ich was nicht richtig schreibe. Ich lass auch mal für Einfügungen ein paar Lücken in der Nummerierung.
Wie gesagt, das ist kein absolut vollständiges Bild. Es fehlen so illustre Dinge wie V-Host-Ermitteln, Authentication, mod_negotiation, mod_speling und viele andere mehr.
Lo!
- mit RequestHeader aus mod_headers kann man an diesem Änderungen vornehmen, nicht aber an der angeforderten URL.
Kommt darauf an, ob man die Sache "early" oder "late" abläuft.
- Die Response ist nun fertig zum Ausliefern, kann aber noch mit Header aus mod_headers beeinflusst werden.
Von php bereits bestehende Header:
Content-Type: text/html
Header set Content-Type "text/css"
Header set Whatever "foobar"
neuer Header:
Content-Type: text/html
Whatever: foobar
Erwartet:
Content-Type: text/css
Whatever: foobar
Lt. Doku sollte mod_headers (sofern nicht das early-Schlüsselwort genutzt wird) auch requests manipulieren: set sollte bestehende Header überschreiben (ansonsten hinzufügen), add nur hinzufügen.
Notiere ich
Header add Content-Type "text/css"
Sollte eigentlich folgendes dabei rauskommen:
Content-Type: text/html
Content-Type: text/css
Rauskommen tut aber nachwievor:
Content-Type: text/html
Was verstehe ich da falsch.
Hi!
- mit RequestHeader aus mod_headers kann man an diesem Änderungen vornehmen, nicht aber an der angeforderten URL.
Kommt darauf an, ob man die Sache "early" oder "late" abläuft.
early und late hab ich weggelassen, da early keine Option für den Dauerbetrieb sein sollte. Um early nutzen zu können, müsstest du außerdem in die Grundkonfiguration eingreifen, was du vermutlich nicht willst. In der .htaccess ist es für early schon zu spät.
- Die Response ist nun fertig zum Ausliefern, kann aber noch mit Header aus mod_headers beeinflusst werden.
Von php bereits bestehende Header:
Content-Type: text/html
Header set Content-Type "text/css"
Header set Whatever "foobar"neuer Header:
Content-Type: text/html
Whatever: foobarErwartet:
Content-Type: text/css
Whatever: foobar
Genau das passiert bei mir (Apache 2.2.14, in der .htaccess gesetzt und mit expliziten Handlern für PHP (spielt hier sicher keine Rolle)).
Lt. Doku sollte mod_headers (sofern nicht das early-Schlüsselwort genutzt wird) auch requests manipulieren: set sollte bestehende Header überschreiben (ansonsten hinzufügen), add nur hinzufügen.
early will ja keiner und du meinst response statt request.
Notiere ich
Header add Content-Type "text/css"Sollte eigentlich folgendes dabei rauskommen:
Content-Type: text/html
Content-Type: text/cssRauskommen tut aber nachwievor:
Content-Type: text/html
Was verstehe ich da falsch.
Das will bei mir auch nicht. Vermutlich aus gutem Grund. Aber
Header set X-Foo bar
Header add X-Foo baz
führt zwar nicht zu
X-Foo: bar
X-Foo: baz
aber immerhin zu
X-Foo: bar, baz
was eigentlich einem append entspricht. Bei 2x set überschreibt es den ersten.
Lo!
Hallo,
es wird dann langsam mal Zeit, dass Du, was von jedem Fragenden erwartet wird, die Versionen der eingesetzten Software präsentierst!
Gruß aus Berlin!
eddi
Re:
- Request kommt rein.
...- Response geht raus.
Ja, perfekt. Wo war dann gestern das Problem, die Möglichkeiten vom mod_header so zu verkennen?
Gruß aus Berlin!
eddi
Hi!
Wo war dann gestern das Problem, die Möglichkeiten vom mod_header so zu verkennen?
Das Problem war meine bis gestern nicht vorhandene Kenntnis dieses Moduls.
Lo!
Re:
Die meisten Hoster setzen dieses Modul auch seltenst ein. Es ist eben kein Modul, was bei den üblichen default-konfigurierten Sourcen mitkompiliert wird. Daher ist auch hier sehr selten die Rede davon. Es ist allerdings, wenn man beispielsweise kein Script nutzt (PHP, etc.), ein sehr wichtiges Modul, was oftmals in Verbindung mit mod_rewrite eingesetzt werden muss (besser müsste), um standardkonform zu bleiben.
# Oftmals eingesetzt und wider RFC 2616:
RewriteCond %{HTTP_USER_AGENT} .*MISE.*
RewriteRule .* http://www.getfirefox.de/ [L]
# richtig dagegen:
RewriteCond %{HTTP_USER_AGENT} .*MISE.*
RewriteRule .* http://www.getfirefox.de/ [L,E=vary:browser]
Header always add Vary "user-agent" vary=browser
Gruß aus Berlin!
eddi
Hi!
Hast du auch noch ein Beispiel bei dem das Verwenden von Filtern als Lösung sinnvoll ist? Die Apache-Doku gibt diesbezüglich nichts her, oder ich habe es nur nicht gefunden.
Lo!
Re:
Hast du auch noch ein Beispiel bei dem das Verwenden von Filtern als Lösung sinnvoll ist? Die Apache-Doku gibt diesbezüglich nichts her, oder ich habe es nur nicht gefunden.
Ähnlich wie milter könnte bspw. ein input-Filter anlandende POST-Daten, sagen wir einen hochgeladenes file, auf Virenbefall untersuchen, deren Zeichenkodierung anpassen oder in Relationen zu anderen Verbindungs- und Requestangaben den Request weiterverarbeiten oder auf HTTP-Ebene ablehnen.
Gruß aus Berlin!
eddi
Hi!
Ähnlich wie milter könnte bspw. ein input-Filter anlandende POST-Daten, sagen wir einen hochgeladenes file, auf Virenbefall untersuchen, deren Zeichenkodierung anpassen oder in Relationen zu anderen Verbindungs- und Requestangaben den Request weiterverarbeiten oder auf HTTP-Ebene ablehnen.
Soweit hatte ich das schon verstanden, nur ist mir noch nicht klar, wo man solch einen Filter herbekommt. Muss man sich da ein Apache-Modul schreiben? - Moment mal, da fällt mir mod_python ein. Sieh an, das "verlängert" Apaches Filterschnittstelle in Richtung Python-Programm. Siehe Overview of a Filter Handler und andere Fundstellen in der Dokumentation.
Lo!
Re:
Soweit hatte ich das schon verstanden, nur ist mir noch nicht klar, wo man solch einen Filter herbekommt.
mod_ext_filter nimmt jedes Programm, was vom stdin list. Das kann also auch python, perl, php sein. Aufgerufen wird das entsprechende Programm via CGI.
Gruß aus Berlin!
eddi
Hallo,
<FilesMatch ".css$">
SetHandler application/x-httpd-php
Header set Content-Type text/css
</FilesMatch>Hat keinen Effekt - ebenso mit Files anstatt FilesMatch
Genauer gesagt: Hat keinen Effekt bei direkten Handlern, nur MIME-Type-Handler sind betroffen.
Dann heißt es einfach mal mitzudenken und Forcetype statt SetHandler zu nutzen. Diese Lösung ist übrigens direkt am Symptom der HTTP-Header, da mod_header ganz zum Schluss einer Anfrage aufgerufen wird - also sogar noch nach PHP. Dennoch ist mod_header leider kein Standardmodul, was hier eine Fehlerquelle sein könnte. Dennoch halte ich ein komplett anderes Vorgehen für besser.
Und im Übrigen bin ich über die Fehlerbeschreibungen, die auf Vorschläge anderer durch suit lapidar in diesem Thread dahingeschnottert werden, offengestanden stinkig. Es ist auch Dir, suit, möglich Auszüge aus den error- und rewrite-logs zu posten, um Dein Problem mit den Vorschlägen einzugrenzen!
Verärgert aus Berlin!
eddi
Hi!
<FilesMatch ".css$">
SetHandler application/x-httpd-php
Header set Content-Type text/css
</FilesMatch>
Hat keinen Effekt - ebenso mit Files anstatt FilesMatch
Genauer gesagt: Hat keinen Effekt bei direkten Handlern, nur MIME-Type-Handler sind betroffen.
Dann heißt es einfach mal mitzudenken und Forcetype statt SetHandler zu nutzen.
Das sage ich doch schon die ganze Zeit, dass Set/AddHandler ein Add/ForceType aushebelt. (Dass ich hier ein temporäres Problem mit "Header set" hatte, was aber sowieso auf einer anderen Baustelle als ForceType spielt, hat sich durch meine Folgepostings aufgeklärt.) Wenn man mit ForceType arbeiten möchte, und einen expliziten Handler gesetzt hat, wie in der PHP-Dokumentation empfohlen (Punkt 8), muss dieser erst deaktiviert werden, sonst ist wie gesagt, das Type-Routing nicht aktiv.
In der Grundkonfiguration:
<FilesMatch "\.php$">
SetHandler application/x-httpd-php
</FilesMatch>
in einer .htaccess:
<FilesMatch "\.php$">
SetHandler None
ForceType application/x-httpd-php-source
</FilesMatch>
Da das aber wie gesagt in erster Linie nur das Routing zum Handler beeinflusst, kann man sich das ForceType auch sparen und gleich mit SetHandler einen expliziten setzen, wenn dieser wie im Falle von PHP sowieso einen eigenen Content-Type erstellt und den "Routing-Type" dafür nicht verwendet.
Lo!
Du könntest auch mal folgendes testen
<?php if (strtolower(substr($_SERVER['SCRIPT_NAME'], -4)) == '.css') header('Content-Type: text/css');
.htaccess
AddType application/x-httpd-php .css
php_value auto_prepend_file "setheader.php"
Wobei du bei setheader.php den kompletten Pfad angeben solltest.
Ich weiß allerdings nicht unter welchen Umständen jetzt die Directive php_value angewendet wird, bei meinem TestServer geht es jedenfalls einwandfrei.
Hatte ich bereits in betracht gezogen und getestet, geht massivst auf die Performance, weil das dann überall vorne angefügt wird - aktuell verfügt das von mir verwendete Framework rund 700-Dateien, die Regelmäßig durch den PHP-Interpreter gejagt werden.
Das funktioniert bei mir
AddType application/x-httpd-php .css
php_value default_mimetype 0
Hallo,
... aktuell verfügt das von mir verwendete Framework rund 700-Dateien, die Regelmäßig durch den PHP-Interpreter gejagt werden.
dann machst Du nach meinem Verständnis einiges falsch. Sieh mal, in wieweit einiges sich (temporär) statisch machen lässt (Grundskizze unter </archiv/2009/6/t188297/#m1253224> und </archiv/2009/6/t188297/#m1253222>).
Gruß aus Berlin!
eddi soll CSS parsen und als text/css ausliefern
eddi soll CSS parsen und als text/css ausliefern
An diesen sch-sch-schönen Mittelklick beim X-Server werde ich mich nie gewöhnen...
dann machst Du nach meinem Verständnis einiges falsch.
Ich? Sicher nicht - ich nutze TYPO3 und da ist das nunmal so, wenn man einen haufen Extensions verwendet. Jede Extension hat ggf. mehrere Plugins/Modulde die je Klasse ein File haben. Da kommt eine Menge zusammen.
Natürlich werden die Dinge gecacht - aber in manchen Fällen ist das caching nicht aktiv (z.B. wenn die Seite für den Cache neu generiert wird) und das kostet dann massivst Performance - besonders, wenn 100.000 "Unterseiten" (bzw. fertige HTML-Dokumente) daraus entstehen.
Hallo suit,
dann machst Du nach meinem Verständnis einiges falsch.
Ich? Sicher nicht - ich nutze TYPO3
^^^^^^^^^^^^^^^
q. e. d.
Wie sieht es denn nun aus mit dem Vorschlag, auto_append_file zu nutzen und dort ein rekursives Durchsuchen des mit $_SERVER['SCRIPT_FILENAME'] benannten Stylesheets zu veranstalten, aus?
Gruß aus Berlin!
eddi
Wie sieht es denn nun aus mit dem Vorschlag, auto_append_file zu nutzen und dort ein rekursives Durchsuchen des mit
$_SERVER['SCRIPT_FILENAME']benannten Stylesheets zu veranstalten, aus?
Ich wusste bislang nicht, dass auto_prepend_file auch in einen Files- oder FilesMatch abschnitt vorkommen darf. Das wäre die notlösung gewesen. :)
Moin!
Ich wusste bislang nicht, dass auto_prepend_file auch in einen Files- oder FilesMatch abschnitt vorkommen darf.
Das tut es gar nicht. Es kommt "php_value" vor. Das "auto_prepend_file" und der nachfolgende String sind aus Sicht des Apache nur Daten.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Das tut es gar nicht. Es kommt "php_value" vor. Das "auto_prepend_file" und der nachfolgende String sind aus Sicht des Apache nur Daten.
i-Tüpferl-Reiter :p
Problem wurde gelöst, danke an alle Helfer (entscheidendes Posting).
Mir ist klar, dass die Lösung (bzw. der Ansatz allgemein) nicht der Knaller ist, aber sie funktioniert :) Vielen Dank.