nicht angemeldet
Hallo,
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" ...
Da hast Du auch wieder Recht *sigh*
Aber zumindest meine Version daddelt alles ab, wenn getenv() nicht funktioniert, sucht er eh die Konfigdatei. Also kann man da auch alles einbauen.
Gut, dann mach ich das mal.
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.
Nunja, liegt wahrscheinlich an meiner Art, Pakete herunterzuladen. ;-)
Ich nehme immer 'wget -c', weil mich a) die herumklickerei in den Browsern nervt und b) es flexibler ist.
Dummerweise macht 'wget -c' folgendes:
Es vergleicht die Dateilänge auf dem Server mit der lokalen. Wenn die auf dem Server größer ist läd er nur den Rest herunter und hängt ihn an die lokale Datei an. Also habe ich in Deinem Falle hier Müll auf der Platte erzeugt ;-)
Warum mußt Du ihn eigentlich anpassen? Wie wäre es mit einem einfachem Link von gzip_cnc.zip auf die jeweilige Version?
Na, Mimetype immer noch fest? ;-)
Ja, weil ich außer HTML keinen Bedarf sehe.
Mmh...
Eigentlich für fast alle text/*, oder?
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 ... ;-)
Aber auf jeden Fall die RFC 2616 lesen ,-)
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body
is defined by its associated media type, as described in section 3.7.
CRLF = CR LF
Mensch, mensch, mensch! Neee, was peinlich wieder ;-)
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.
Ist zumindest jetzt in der Distribution mit drin.
Müßte man mal recherchieren seit wann.
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).
Ja, sowas kann ich nur unterstützen.
(Solange es keine furchtbaren Verrenkungen kostet, natürlich ;-)
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.
Aber Du kannst Dir trotzdem Deinen eigenen Header basteln.
Sollte das nicht einen 404 geben? ;-)
Äh, ja, sollte es wohl.
Es mag Geschmacksache sein, aber als alter wget Benutzer bekomme ich bei solchen Redirects im 404 Falle immer einen dicken Hals, da ich jedesmal bei kaputten Links die 404-Datei herunterladen muß.
(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.
Redirekt: 302
File Not Found: 404
Das ist nunmal so festgelegt.
An den 404 kannst Du auch noch Daten dranhängen, das ist also auch kein Hinderungsgrund. Und es ist ja egal wo die Daten herkommen, ob direkt im Code, oder aus einer Datei gelesen.
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?
Ist möglich.
(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.
Aha, soso ;-)))
Ist die Adresse auf Deiner Seite unten aktiv?
Sprich: holst Du da was ab?)
Sagen wir mal: Es sollte ankommen.
Na, das ist mir etwas zuwenig ;-)
Wenn Du einen Filter laufen läßt könnten wir uns evt auf
/^Subject:[\s]*(Re:)*[\s]*88a43603fcfc2f7e7c6646cd4b89180a/
einigen?
(Stimmt die Regex überhaupt? ;-)
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.
Nein, das ist auch nicht sinnvoll.
Und schon gar nicht den gesamten Apache.
Das wäre aber zumindest mal interessant, aber wohl auch eher etwas für die einsame Insel ;-)
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.)
Nun, den Filter wollte ich genauso einbauen, wie gzip_cncc auch.
Ob das so funktioniert ist natürlich eine andere Frage.
Ist nicht viel Arbeit, ich versuchs einfach mal ;-)
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 ...
Soweit kein Problem, aber
und wie Du
das dechunking lösen würdest, wüßte ich auch gern.
Das könnte eines werden.
Aber wie gesagt, ist nicht allzuviel Arbeit und "Versuch nacht kluch!"
(und wenn man sonst auch nichts erhalten mag, so doch ein wenig Erfahrung ;-)
so short
Christoph Zurnieden