nicht angemeldet
Hi,
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.
So groß sind die Binaries nicht, das man nicht zwei
anbieten könnte.
Und Du glaubst, die DAUs begreifen, welchen der beiden
Downloads sie brauchen?
Das ist ja schlimmer als "configure --help" ...
Argh, Sch..., würdest Du mal bitte Deine Pakete mit
Versionsnummern bestücken? Danke!
Was genau meinst Du damit?
Die Versionsnummer steht doch im Skript drin.
Und der Link auf die Download-Datei steht in den HTML-
Seiten drin - den passe ich bestimmt nicht ständig an.
Na, Mimetype immer noch fest? ;-)
Ja, weil ich außer HTML keinen Bedarf sehe.
HTTP standard line separator
my $crlf = "\015\012";
Ogottogott, ich hab _immer_ noch nur \n drin.
Ich habe das auch nur aus dem Self-Forum abgeschrieben
- glaub doch nicht, ich könnte programmieren ... ;-)
Die Timezone als GMT festzulegen ist ja auch nicht
gerade die feine Art, oder? ;-)
Wie geht es richtig? Ich habe bloß gesehen, daß es bei
mir funktioniert hat ...
Wenn das POSIX Paket drin ist, kannst Du strftime
benutzen, da wäre es '%Z'
IMHO ist das in Activeperl mit dabei.
ActivePerl ist aber ein wilder Sonderfall - der Normal-
fall sind UNIXe mit Uralt-Perl, denke ich.
Eigentlich will ich, daß es mit allen Perl5s läuft -
deshalb auch keinerlei Modul-Referenzen (d. h. die
zlib-API nur optional und make-path im Selbstbau).
Achja, auch Du mein Sohn baust Redirects für "File
not found" ein, ja?
Das Problem ist, daß das, was ich eigentlich will,
m. E. gar nicht geht, weil ich kein Modul bin,
sondern nur ein Handler.
Sollte das nicht einen 404 geben? ;-)
Äh, ja, sollte es wohl.
(Sollte der Redirect nicht auch mit einem 302
angekündigt werden, oder habe ich da was übersehen?)
Was denn nun? Ich mache den Redirect nur im 404-Fall.
Ja, es geht, schau mal in mein Paket.
Bisher mache ich da einfach nichts - der Apache klebt
wohl selbst eine 302 davor, wenn der "Location" findet?
(Das ist wahrscheinlich schlecht, ich schicke die
Dinger immer noch an Deine Arbeit.
Wenn ich nicht gerade Urlaub hätte, wäre das sogar
optimal.
Ist die Adresse auf Deiner Seite unten aktiv?
Sprich: holst Du da was ab?)
Sagen wir mal: Es sollte ankommen.
Das mit der mangelnden Komprimierbarkeit von
dynamischen Inhalten stört mich doch etwas.
Das fehlt irgendwie.
Mir nicht.
Ich will nicht mod_gzip in Perl reimplementieren.
Und schon gar nicht den gesamten Apache.
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?
Wie willst Du den Filter dort einbauen? Im Apache geht
es nur so, wie mod_gzip das macht (denke ich); im CGI-
Skript wäre es wiederum spezifisch für jede Sprache.
(Für PHP gibt es so etwas schon mehrfach, für Perl
könnte man es über zlib::API und stdout-Pufferung sicherlich auch bauen, das ist aber nicht, was ich
will. gzip_cnc hat nicht Programmierer als Zielgruppe.)
Nur Content-Length wäre schwierig einzubauen.
Wieso? Wenn Du eh in einem Puffer komprimieren mußt,
mußt Du den Puffer auch aufmachen, STDOUT dorthin um-
leiten, zwischen Headern und Body trennen, den Body
komprimieren und die Header umschreiben. Bedenke, daß
ein paar zusätzliche Header rein müssen ... und wie Du
das dechunking lösen würdest, wüßte ich auch gern.
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael