nicht angemeldet
Hallo,
hatten wir nicht geklärt, daß "SetEnv" doch
nicht "böse" wäre?
Dann habe ich irgendwas nicht mitbekommen ;-)
in diesem Riesen-Thread finde ich jetzt gerade das
genaue Posting nicht - es lief aber darauf hinaus,
daß SetEnv und Action beides dieselbe AllowOverride-
Klasse ist - wenn das eine erlaubt ist, dann ist
normalweise das andere auch erlaubt.
"Normalerweise" ist immer so eine Sache ;-)
(Es sei denn, mod_env ist als Apache-Standard-Modul
überhaupt nicht installiert ... wie beispielsweise
genau bei meinem Provider, gnlpfts.)
Tja, wie sagte doch gleich dieser amerikanische Luftwaffeningenieur so treffend? ;-)
Compatibility: SetEnv is only available in Apache
1.1 and later. Directory and .htaccess context is
available in Apache 1.3.7 and later.
.htaccess wird also erst seit 1.3.7 unterstützt.
Ist die veraltet genug, oder noch in signifikanter
Anzahl online?
Wenn nicht ausgerechnet der Provider des einzigen mir
bisher bekannten nur-Testfliegers (Thomas J. S.) einen
Apache 1.3.3 (!)
Au Mann ;-)
verwenden würde, hätte ich darüber
milde gelächelt ...
Auch das hat o.a. Herr Murphy schon vorrausgesehen ;-)
Allerdings bräuchtest Du eigentlich sogar SetEnvIf:
Wozu?
Könnte man sich den Browsertest (NN 4.06-8) auch noch sparen.
Ich kann doch mehrere MIME-Typen durch mehrere separate
Einbindungen lösen und jeweils innerhalb der <Files>-
Klammer eine andere SetEnv-Direktive verwenden.
Zu kompliziert. Da dürfte die Userakzeptanz gegen stehen.
(Das sind die, denen ein './configure --help && ./configure --with-several-options && make install' schon zu kompliziert ist, müßten sie ja die Ausgabe von configure --help lesen, oder gar das README auch noch!)
Also meine Frage: sind die Dinger so alt, daß man
sie getrost ignorieren kann?
Das kommt darauf an.
Siehe oben >;->
Ein Provider, der etwas Älteres als 1.3.7 einsetzt,
macht m. E. irgendwas gründlich verkehrt; das ist aber
ähnlich wie bei einem Besucher mit Netscape 4. Fragt
sich halt, ob wir ihn dafür büßen lassen wollen. ;-)
(Lokal läuft hier 1.3.6, für mich reichts ;-) Von den aktuellen habe ich mir aber doch stets die Doku gezogen. Man muß ja nicht alles wissen, Hauptsache man weiß wer es nachschlagen kann, gell? ;-)
Zumindest bei 1.3.3 meine ich mich vage an eine ziemlich fiese Sicherheitslücke entsinnen zu können. Kann mich aber natürlich auch irren.
gzip_cnc hat es da mal wieder leichter - dort wäre die
Konfigurierbarkeit via Environment nur eine zusätzliche
Option, während es bei gzip_cnc-Binaries eine echte
Einschränkung darstellen würde.
Ach nö, würde ich nicht sagen. Ist ja eine Grundsituation und deshalb kann schlecht beides auf einem Server vorkommen. Entweder es geht, oder nicht.
So groß sind die Binaries nicht, das man nicht zwei anbieten könnte.
Ist eh (so man meine Version nimmt) via configure einstellbar (und per default aus) beim Bau aus den Quellen. Man könnte auch eine Config basteln (Ist ja normalerweise sogar schon eine da ;-), aber der Overhead!
(Nein, fork()erei bau ich nicht ein! Man kann es auch übertreiben!;-)
Insofern habe ich es für gzip_cnc 1.07 einfach mal
eingebaut:
http://www.schroepl.net/projekte/gzip_cnc/changes.htm#v1.07
Na, dann schau ich mal.
Argh, Sch..., würdest Du mal bitte Deine Pakete mit Versionsnummern bestücken? Danke!
*grrr*
;-)
Gut, alle Environmentvariablen mit GZIP_CNC_ Präfix? Dann ändere ich das mal. Ist bei mir hier noch etwas durcheinander ;-)
Na, Mimetype immer noch fest? ;-)
Aber was grinse ich da so unverschämt, ich habe das ja auch erstmal nur wenig elegant gelöst.
SELFTEST.
Mmh...
Ein wenig Debugging Infos sind nicht schlecht, ja, gute Idee.
HTTP standard line separator
my $crlf = "\015\012";
Ogottogott, ich hab _immer_ noch nur \n drin. Verdammt, das macht halt die Gewohnheit. Wie immer halten sich ja die Schlechten am längsten, nicht? ;-)
Die Timezone als GMT festzulegen ist ja auch nicht gerade die feine Art, oder? ;-)
Wenn das POSIX Paket drin ist, kannst Du strftime benutzen, da wäre es '%Z'
IMHO ist das in Activeperl mit dabei.
Achja, auch Du mein Sohn baust Redirects für "File not found" ein, ja?
Sollte das nicht einen 404 geben? ;-)
(Sollte der Redirect nicht auch mit einem 302 angekündigt werden, oder habe ich da was übersehen?)
Ja, es geht, schau mal in mein Paket.
(Das ist wahrscheinlich schlecht, ich schicke die Dinger immer noch an Deine Arbeit. Ist die Adresse auf Deiner Seite unten aktiv? Sprich: holst Du da was ab?)
Das mit der mangelnden Komprimierbarkeit von dynamischen Inhalten stört mich doch etwas. Das fehlt irgendwie. Mittlerweile wird ja doch ein steigender Prozentsatz selbst bei privaten Seiten dynamisch erzeugt. Könnte sowas nicht ein Filter zwischen CGI-Programm und STDOUT erledigen? Muß ja nur den Header überspringen können. Das Schöne am Gzip-Algorithmus iat ja, das man damit auch Streams komprimieren kann.
Nur Content-Length wäre schwierig einzubauen.
Wäre sowas praktikabel und vor allem: bequem zu benutzen?
so short
Christoph Zurnieden