gzip_cnc

[Michael Schröpl]

Hallo Leute,

jetzt mache ich auch mal ein Faß, äh - einen Thread auf.

In den letzten Tagen sind Christian Kruse und ich ein
wenig 'abgetaucht'. Das hatte seinen Grund, und der
hat inzwischen die Versionsnummer 1.05 ... und heißt
gzip_cnc.

Bekanntlich wird ein Großteil der Seiten dieses Servers
hier durch den Einsatz des Apache-3rd-party-Moduls
"mod_zip" in komprimierter Form ausgeliefert, was bei
SelfHTML 8.0 ungefähr 60% und bei der Forumshauptdatei
etwa 90% der übertragenen Datenmenge einspart.

Nur setzt die Verwendbarkeit von mod_gzip leider
voraus, daß es vom Provider installiert und in den
Apache eingebunden wird (und korrekt konfiguriert,
was auch nicht gerade einfach ist).
Und so arg viele Provider mit mod_gzip habe ich bisher
in Deutschland noch nicht gefunden.

Außerdem hat der Einsatz von mod_gzip gezeigt, daß die
CPU-Belastung beim ständigen Komprimieren der immer
wieder gleichen Seiten nicht völlig zu vernachlässigen
ist.
mod_gzip kann nicht anders (noch! ;-), weil es stati-
sche und dynamische Inhalte gleichermaßen komprimiert
ausliefern kann und nicht versucht, zwischen beiden
irgendwie zu unterscheiden.

Dafür kann mod_gzip bereits statisch vorkomprimierte
Seiten optional ausliefern (per Content Negotiation) -
das ist der Mechanismus, mit dem bisher die Online-
Version von SelfHTML 8.0 angeboten wird (das geht irre
schnell und belastet die CPU praktisch nicht.
Das bedeutet natürlich, daß man die komprimierten Ver-
sionen jedesmal neu erzeugen muß, wenn sich das Ori-
ginal geändert hat ... vergißt man das, dann bekommt
die überwiegende Mehrzahl der Besucher veraltete In-
halte angeboten.

Ausgehend von dieser Situation haben Christian und ich
ein System diskutiert, entworfen, implementiert, ge-
testet, von Perl nach C portiert und ausführlich doku-
mentiert, welches die folgenden Eigenschaften aufweisen
soll:
1. Es soll ohne Änderung des Webserver-Codes, also ohne
   Eingriff des Providers bzw. Webmasters, verwendbar
   sein.
2. Es soll jeden Datei-Inhalt nur ein einziges Mal kom-
   primieren und selbständig prüfen, ob diese kompri-
   mierte Instanz veraltet ist, d. h. neu erzeugt wer-
   den muß.
Dabei wurde bewußt darauf verzichtet, dynamische Seiten
aller Art komprimieren zu können - wenn man _das_ will,
dann _muß_ man in den Webserver hinein und dort etwas
einbauen. gzip_cnc ist kein Ersatz für mod_gzip.

Die Voraussetzungen für den Einsatz von gzip_cnc sollen
sich im üblichen Rahmen gängiger Webspace-Angebote be-
wegen: CGI, Perl und .htaccess - das muß reichen.
Die Zielgruppe ist also "der typische Seitenkleber". ;-)

Genug des Palavers - das hier isses:
   http://www.schroepl.net/projekte/gzip_cnc/

Jetzt könnte ich eigentlich noch "viel Spaß beim Lesen
und Installieren" scheiben und fertig ...
Aber ich möchte gerne die Gelegenheit nutzen, Verbes-
serungsvorschläge 'einzusammeln'.
Im Großen und Ganzen stehen die Seiten - aber nach
fünfmal Korrekturlesen bin ich im Stadium massiver
Betriebsblindheit.

Deshalb: Jede Anmerkung, die zur Verbesserung von
gzip_cnc und seiner Dokumentation führen können, wird
dankend angenommen - wahlweise hier im Forum oder auch
per Mail.
Rechtschreibfehler, broken links, Verständlichkeit der
Formulierungen, Probleme beim Ausprobieren ... immer
her damit.

Also dann: Auf geht's, Leute!

Viel Spaß beim ...
     Michael

P.S.: Falls mir beispielsweise jemand erklären könnte,
      was ich in meinem CSS verkehrt mache ... die
      Navigation sollte eigentlich in allen Browsern
      so aussehen wie im M$IE, also mit gleich breiten
      hover-Balken ...

[Stefan Einspender]

Hallo Michael,

P.S.: Falls mir beispielsweise jemand erklären könnte,
      was ich in meinem CSS verkehrt mache ... die
      Navigation sollte eigentlich in allen Browsern
      so aussehen wie im M$IE, also mit gleich breiten
      hover-Balken ...

der einfachste Weg wird wohl sein, wenn Du Dir http://favicon.de/ an-
schaust und dort hemmungslos Quelltext klaust ;-)

Eventuell mußt Du noch zwischen die a-Elemente jeweils ein <br> rein-
setzen, weil Du ja (leider) ein tabellenbasiertes Layout verwendest
und da sieht es ohne CSS komisch aus, wenn die Links einfach hinter-
einander in einer Spalte stehen.

Wenn Du nicht klauen willst, dann hier die Kurzanleitung:
-alle span-Elemente in td#nav raus
-alle div-Elemente in td#nav raus
-für alle a-Elemente in der td#nav display:block und die gewünschte
 Breite per CSS festlegen, sowie alle anderen gewünschten Eigen-
 schaften, also td#nav a { background:#123456; } usw.

Viele Grüße,
Stefan

[Michael Schröpl]

Hi Stefan,

Eventuell mußt Du noch zwischen die a-Elemente
jeweils ein <br> reinsetzen, weil Du ja (leider)
ein tabellenbasiertes Layout verwendest

Alternativ-Vorschläge werden gerne genommen ... ich
hänge nicht an den Tabellen, es ging nur am einfach-
sten mit ihnen.
Meine Erfahrungen mit absolut positionierten <div>s
sind ziemlich genau Null ... und ich hatte keinen
Grund, Netscape 4 unnötig weh zu tun.

BTW: Wie kann ich ein "<br clear="all"> in CSS
nachbilden?
(Netscape 4 malt sonst das Logo über die Navigations-
 Links ... ich möchte aber bei XHTML 1.1 bleiben.)

und da sieht es ohne CSS komisch aus, wenn die
Links einfach hintereinander in einer Spalte stehen.

Tun sie bei mir nicht (M$IE 5.5, Opera 6, Mozilla 1.0,
Netscape 4.79). Bei Dir etwa schon?

Wenn ich jeweils <br /> rein mache, bekomme ich zudem
einen doppelten Zeilenabstand - den will ich natürlich
nicht haben ...

-für alle a-Elemente in der td#nav display:block

Yep - genau das hat mir gefehlt, danke. :-)
Das schon jetzt _viel_ besser aus ...

Viele Grüße
      Michael

[Stefan Einspender]

Hallo Michael,

Alternativ-Vorschläge werden gerne genommen ... ich
hänge nicht an den Tabellen, es ging nur am einfach-
sten mit ihnen.

da ich eh vorhabe, mir die Sache demnächst mal etwas genauer anzu-
schauen, kann ich da Dir vielleicht auch etwas unter die Arme
greifen, verdient hast DU es ganz bestimmt :-)

BTW: Wie kann ich ein "<br clear="all"> in CSS
nachbilden?

wenn ich sage, dass Stichwort lautet "clear" und Dich auf das
CSS-Syntaxverzeichnis von SELFHTML verweise, hilft es sicher ein
Stück weiter: http://de.selfhtml.org/navigation/syntax.htm#css_c ;-)

Tun sie bei mir nicht (M$IE 5.5, Opera 6, Mozilla 1.0,
Netscape 4.79). Bei Dir etwa schon?

Ohne CSS stehen sie dann direkt hintereinander und eventuell auch
mehrere in einer Zeile, je nachdem, wieviele in die Tabellenzelle
passen. Bei einem komplett CSS-basierten Layout ist sowas kein
Problem, bei Tabellenlayout sieht es u.U. recht eigenartig aus.

Viele Grüße,
Stefan

[Orlando]

Hi, Michael und Stefan

Alternativ-Vorschläge werden gerne genommen ... ich
hänge nicht an den Tabellen, es ging nur am einfach-
sten mit ihnen.

da ich eh vorhabe, mir die Sache demnächst mal etwas genauer anzu-
schauen, kann ich da Dir vielleicht auch etwas unter die Arme
greifen, verdient hast DU es ganz bestimmt :-)

*klopf-klopf* ;)

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Zapp]

Hallo Stefan,

der einfachste Weg wird wohl sein, wenn Du Dir http://favicon.de/ an-
schaust und dort hemmungslos Quelltext klaust ;-)

Er sollte den Code aber auch nicht unbesehen klauen, denn ich war mit IE5.0 auf deiner Seite, und meistens fehlte die Navigation. Oft kam die erst nach einem Reload, aber auch nicht immer, und im Offline-Modus dann gar nicht mehr. Nach etwas Rumprobieren stellte sich heraus, dass IE zwei im Print-Abschnitt auf "DISPLAY: none" gesetzte Elemente (DIV#navigation, IMG) dann im Screen-Abschnitt auf einen "sichtbaren" Wert gesetzt haben möchte.
Und auch der Screenshot "beispiel.png" wurde erst angezeigt, nachdem ich "POSITION: fixed" herausgenommen hatte.

Grüße, Stefan

[Stefan Einspender]

Hallo Stefan,

dito :-)

Nach etwas Rumprobieren stellte sich heraus, dass IE zwei im Print-Abschnitt auf "DISPLAY: none" gesetzte Elemente (DIV#navigation, IMG) dann im Screen-Abschnitt auf einen "sichtbaren" Wert gesetzt haben möchte.

habe jetztmal die print-Anweisungen unter die screen-Anweisungen
im Stylesheet gesetzt, vielleicht reicht das ja schon aus. Ich wäre
Dir dankbar, wenn Du nochmal schauen könntest, ob das Problem noch
auftritt. Ansonsten werde ich dann wohl img { display: inline; }
usw. dazuschreiben müssen :-(

Hat eigentlich schonmal jemand erwähnt, dass der MSIE bezüglich CSS
nicht "Stand der Technik" ist? OK, in der aktuellen Version gibt es
dieses Problem nicht, aber dafür genug andere Ungereimtheiten.

Und auch der Screenshot "beispiel.png" wurde erst angezeigt, nachdem ich "POSITION: fixed" herausgenommen hatte.

habe ich jetzt auchmal etwas geändert, allerdings bin ich mir nicht
sicher, ob es jetzt eventuell in anderen Browsern unangenehme Be-
gleiterscheinungen nach sich zieht. Über eventuelle Fehlermeldungen
wäre ich dankbar.

Viele Grüße,
Stefan

[Zapp]

Hi,

habe jetztmal die print-Anweisungen unter die screen-Anweisungen
im Stylesheet gesetzt, vielleicht reicht das ja schon aus.

Leider nein, das hatte ich auch schon probiert. Es würde nur helfen, den print-Block ganz rauszuwerfen.

Hat eigentlich schonmal jemand erwähnt, dass der MSIE bezüglich CSS
nicht "Stand der Technik" ist?

Gehört hab' ich das auch schon mal, aber sicher nicht hier in diesem Forum, da hier ja traditionell eher nach Haaren in der Mozilla-Suppe gefahndet wird. ;>

Nee, aber im Ernst: das mit position: fixed ist schon sehr ärgerlich, und da wäre es dann ein Lichtblick, wenn man IE und position: fixed irgendwie unter einen Hut bringen könnte. Vor Kurzem gab es ja einen Thread zu dem Thema, aber bisher hatte ich noch keine Seite dazu gesehen. Bis auf die Sache mit dem Bild sieht das bei dir aber ja sehr vielversprechend aus.

Und auch der Screenshot "beispiel.png" wurde erst angezeigt, nachdem ich "POSITION: fixed" herausgenommen hatte.

habe ich jetzt auchmal etwas geändert, allerdings bin ich mir nicht
sicher, ob es jetzt eventuell in anderen Browsern unangenehme Be-
gleiterscheinungen nach sich zieht. Über eventuelle Fehlermeldungen
wäre ich dankbar.

Auch hier gibt es leider keine Veränderung. Es wird Freiraum für das Bild reserviert, und es ist offensichtlich, dass da was fehlt.
Wenn ich Zeit habe, könnte ich auch noch mal dieses und jenes testen, mich interessiert das auch. Viel Erfahrung mit CSS habe ich allerdings nicht.

Grüße, Stefan

[Stefan Einspender]

Hallo Stefan,

Leider nein, das hatte ich auch schon probiert. Es würde nur helfen, den print-Block ganz rauszuwerfen.

eigentlich wollte ich jetzt schreiben:
"Was für eine Scheisse hat da Microsoft eigentlich auf den Markt
 geworfen? Wenn innerhalb von @media print { } CSS-Definitionen
 stehen, dann sind die gefälligst nur beim Ausdruck zu beachten
 oder komplett zu ignorieren, falls der Browser zu dumm ist"

Naja, jedenfalls habe ich jetzt nochmal ganz schön einzeln für den
screen-Anweisungsteil gesagt, wie er mir die Bilder anzeigen soll,
dass da die Navigation hingehört usw.
Kannst Du bitte nochmal schauen, wie http://favicon.de/ jetzt bei
Dir ausschaut?

Wenn ich Deine Schilderungen so höre, sollte ich mir tatsächlich
mal wieder ein Zugang zu älteren MS-Browsern verschaffen, dank der
geradezu "genialen" Monoinstallationskultur des MSIE ist sowas ja
auch nicht so leicht :-/

Auch hier gibt es leider keine Veränderung. Es wird Freiraum für das Bild reserviert, und es ist offensichtlich, dass da was fehlt.

Hm ... habe jetzt nochmal hingeschrieben, dass da das Bild hinge-
hört, bekommt er es jetzt gerafft?
Wenn nicht, dann weiß ich für den Moment auch nicht weiter, ich
will gern eine CSS-Datei verwenden und auch für einen möglichen
Ausdruck CSS-Defintionen anbieten können.

So, jetzt löse ich erstmal das Orlando-Problem, die Sache wird
hoffentlich nicht so ärgerlich enden ;-)

Viele Grüße,
Stefan

[Orlando]

Hi, Stefan

So, jetzt löse ich erstmal das Orlando-Problem

Ich hab's ehrlich nicht so gemeint, bitte... hiiiiiiilfääääääääää!!!!1

LG Orlan*dankebuntefaviconshabichamliebsten*do

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Zapp]

Hallo Stefan,

Naja, jedenfalls habe ich jetzt nochmal ganz schön einzeln für den
screen-Anweisungsteil gesagt, wie er mir die Bilder anzeigen soll,
dass da die Navigation hingehört usw.

Die Navigation ist jetzt in Ordnung!
Das Bild fehlt aber nach wie vor, allerdings nur das auf der Startseite. Die Bilder unter "Browser" sind nicht betroffen.

Grüße, Stefan

[Zapp]

Hallo Stefan,

eigentlich wollte ich jetzt schreiben:
"Was für eine Scheisse hat da Microsoft eigentlich auf den Markt
geworfen? Wenn innerhalb von @media print { } CSS-Definitionen
stehen, dann sind die gefälligst nur beim Ausdruck zu beachten
oder komplett zu ignorieren, falls der Browser zu dumm ist"

Klar, aber das Ding ist von 1999 (wie beispielsweise Opera 3.5), und auch heute noch problemlos einsetzbar.

http://favicon.de/

Der Bug mit den nicht angezeigten Bildern bei "position: fixed" ist ganz schön krass: Bilder werden nur angezeigt, wenn sie beim Seitenaufbau am unteren Rand des sichtbaren Bereichs oder tiefer stehen. Ansonsten gibt's eine freie Stelle, die sich aber z.B. bei Rechsklick so verhält, als sei sie das Bild. Und auch wenn Bilder zu sehen sind, werden sie beim Ändern der Fensterbreite ausgeblendet.

Aber wenn man den IE ganz einfach von "position: fixed" ausnehmen kann, ist das ja vielleicht alles kein Problem: http://jendryschik.de/wsdev/css/fixed/ (wonach auch Opera Probleme haben soll).

Grüße, Stefan

[Orlando]

Hi, Michael

jetzt mache ich auch mal ein Faß, äh - einen Thread auf.

Ein 'Prost' auf euch beide! Tja, inhaltlich habe ich leider (noch?) nicht besonders viel zu sagen, also beschränke ich mich auf das Layout.

Screenshot von N4.78: <img src="http://www.skop.net/self/gzip_cnc_n4.gif" border=0 alt="">

Die ersten Links sind nicht anklickbar, da hilft wahrscheinlich

td#nav img {display: block;}

oder die Einbindung des Bildes in ein Block-Element wie <p>:

<p><img src="gzip_cnc.gif" height="96" width="96" alt="gzip_cnc-Logo" /></p>

Vom Einsatz von <small> rate ich ab, der Text wird arg klein und unterbricht den Lesefluss. Eine leicht abweichende Farbe wäre IMHO besser geeignet.

Die Schriftgrößen mit px zu zementieren, verhindert die manuelle Änderung derselben im IE und ist nicht notwendig.

Huch! Ein mailto-Link. Soll ich dir einen Formmailer schreiben? ;p

Ich hätte auf Tabellen verzichtet und die Elemente mit CSS positioniert, eine fixierte Navigation wäre zB sehr praktisch. Vielleicht triffst du ja mal wen, der sich dafür interessiert ;)

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Orlando,

Screenshot von N4.78: <img src="http://www.skop.net/self/gzip_cnc_n4.gif" border=0 alt="">

Heul ... ich weiß.

Die ersten Links sind nicht anklickbar, da hilft
wahrscheinlich
  td#nav img {display: block;}
oder die Einbindung des Bildes in ein Block-Element wie <p>:
  <p><img src="gzip_cnc.gif" height="96" width="96" alt="gzip_cnc-Logo" /></p>

Weder noch. Ich habe beides ausprobiert.

Ich glaube, ich werde das Problem durch eine andere
Tabellenstruktur angehen ...

Vom Einsatz von <small> rate ich ab, der Text wird
arg klein und unterbricht den Lesefluss.

Damit habe ich so meine Schwierigkeiten.

Ich selbst arbeite mit 1280*1024, denke also, daß die
Schrift bei den meisten Benutzern größer sein wird als
bei mir. Reicht das wirklich nicht aus?

Eine leicht abweichende Farbe wäre IMHO besser
geeignet.

Mag sein. Aber dieses Stilmittel nehme ich schon für
<em> und <strong>. Geklammerte Anmerkungen sind i.d.R.
etwas, was ich bei anderen Textformaten als Fußnote
layoutet hätte - deshalb _will_ ich sie kleiner haben
als den Rest, damit man sie 'schwungvoll' überlesen
kann, d. h. das Ende des Einschubs sieht, ohne ihn
dafür komplett lesen zu müssen.

Vielleicht sollte ich dafür sogar eher Tooltips oder
Ähnliches einbauen ... aber JavaScript (overlib etc.)
ist mir die Sache an dieser Stelle nicht wert, und
formatierte echte Tooltips können wiederum die alten
Browser nicht.

Die Schriftgrößen mit px zu zementieren, verhindert
die manuelle Änderung derselben im IE und ist nicht
notwendig.

In dieser Hinsicht stehe ich auf derselben Seite wie
Stefan Münz, der für SelfHTML ja auch eine Schrift-
größe vorgibt. (Ein Grund mehr, keinen M$IE zu nehmen

• richtige Browser können ja drüber skalieren. ;-)

Huch! Ein mailto-Link. Soll ich dir einen Formmailer
schreiben? ;p

Ich habe einen Form-Mailer auf meiner Domain im Ein-
satz ... aber was spricht gegen einen mailto-Link?
(Es ist ja kein mailto-Formular ...)

Ich hätte auf Tabellen verzichtet und die Elemente
mit CSS positioniert, eine fixierte Navigation wäre
zB sehr praktisch. Vielleicht triffst du ja mal wen,
der sich dafür interessiert ;)

Was würde Netscape 4 _davon_ halten, wenn er schon
nicht mal das Bild gebacken kriegt? :-(

Viele Grüße
      Michael

[Stefan Einspender]

Hallo Michael,

Was würde Netscape 4 _davon_ halten, wenn er schon
nicht mal das Bild gebacken kriegt? :-(

schau Dir http://www.webstandards.org/ mit diesem Browser an, viel
mehr ist da nicht, warum auch? Technisch veralteter Browser, Inhalt
ist komplett zugänglich, warum sollte man nicht so arbeiten?

Der Anteil von Surfern mit diesem Browser nimmt weiterhin permanent
ab und NC7 wird dazu sicher noch ein ganzes Stück beitragen.

Ansonsten siehe meine Hinweise in ?m=78496&t=14094, am Wochenende
schaue ich mir die ganze Website mal genauer an :-)

@Orlando:
Jaja, ich weiß schon  ... *notizzetellschreibpostitanderbildschirmhängknoteninstaschentuchmachtodolistenanleg*

;-)

Viele Grüße,
Stefan

[Orlando]

Hi Michael,

<img src="http://www.skop.net/self/gzip_cnc_n4.gif" border=0 alt="">

Ich glaube, ich werde das Problem durch eine andere
Tabellenstruktur angehen ...

das wirst du nicht -> http://selfhtml.teamone.de/css/eigenschaften/ ;)

Vom Einsatz von <small> rate ich ab

Ich selbst arbeite mit 1280*1024, denke also, daß die
Schrift bei den meisten Benutzern größer sein wird als
bei mir. Reicht das wirklich nicht aus?

<img src="http://www.skop.net/self/gzip_cnc_small.gif" border=0 alt="">

Mir persönlich ist das zu klein, ich arbeite mit 1152*864.

Eine leicht abweichende Farbe wäre IMHO besser
geeignet.

Mag sein. Aber dieses Stilmittel nehme ich schon für
<em> und <strong>. Geklammerte Anmerkungen sind i.d.R.
etwas, was ich bei anderen Textformaten als Fußnote
layoutet hätte - deshalb _will_ ich sie kleiner haben
als den Rest, damit man sie 'schwungvoll' überlesen
kann, d. h. das Ende des Einschubs sieht, ohne ihn
dafür komplett lesen zu müssen.

Eine gute Idee, doch ich fürchte, dass gerade das Zielpublikum sich auch für die zusätzlichen Erläuterungen interessieren wird.

Vielleicht sollte ich dafür sogar eher Tooltips oder
Ähnliches einbauen ... aber JavaScript (overlib etc.)
ist mir die Sache an dieser Stelle nicht wert, und
formatierte echte Tooltips können wiederum die alten
Browser nicht.

Was hältst du von Fußnoten am Ende der Seite?

Die Schriftgrößen mit px zu zementieren, verhindert
die manuelle Änderung derselben im IE und ist nicht
notwendig.

In dieser Hinsicht stehe ich auf derselben Seite wie
Stefan Münz, der für SelfHTML ja auch eine Schrift-
größe vorgibt.

Schöne Grüße von der sonnigen Seite. ;)

(Ein Grund mehr, keinen M$IE zu nehmen

• richtige Browser können ja drüber skalieren. ;-)

Davon hat dich große Mehrheit leider wenig. Wie war das nochmal mit deiner Akzeptanz von Monopolen? ;p

Huch! Ein mailto-Link. Soll ich dir einen Formmailer
schreiben? ;p

Ich habe einen Form-Mailer auf meiner Domain im Ein-
satz ... aber was spricht gegen einen mailto-Link?

Er funktioniert leider nicht zuverlässig.

Ich hätte auf Tabellen verzichtet und die Elemente
mit CSS positioniert, eine fixierte Navigation wäre
zB sehr praktisch. Vielleicht triffst du ja mal wen,
der sich dafür interessiert ;)

Was würde Netscape 4 _davon_ halten, wenn er schon
nicht mal das Bild gebacken kriegt? :-(

Das ist kein Problem. Meine Baustelle (http://www.skop.net/preview/) sieht zwar in N4.x, IE und Opera/Mozilla jeweils etwas anders aus, die Seite funktioniert trotzdem überall. Der alte Netsie versteht CSS durchaus, man muss nur wissen, was man ihm zumuten kann. Einen Versuch ist es allemal wert, Unterstützung ist hiermit zugesagt.

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Orlando,

Ich glaube, ich werde das Problem durch eine andere
Tabellenstruktur angehen ...
das wirst du nicht -> http://selfhtml.teamone.de/css/eigenschaften/ ;)

Ich habe es tatsächlich versucht (zwei Zeilen links,
eine zweizeilige Zelle rechts), bin aber daran ge-
scheitert, die untere linke Zelle top-bündig auszu-
richten - was immer ich versucht habe, im M$IE klappte
es nicht (als einzigem Browser).
Da war mir der M$IE dann doch wichtiger als Netscape 4 ...

bei mir. Reicht das wirklich nicht aus?
<img src="http://www.skop.net/self/gzip_cnc_small.gif" border=0 alt="">
Mir persönlich ist das zu klein, ich arbeite mit 1152*864.

Ich finde das insbesonders deshalb interessant, weil
ich selbst ja auch so schlechte Augen habe ...

<em> und <strong>. Geklammerte Anmerkungen sind i.d.R.
etwas, was ich bei anderen Textformaten als Fußnote
layoutet hätte - deshalb _will_ ich sie kleiner haben
als den Rest, damit man sie 'schwungvoll' überlesen
kann, d. h. das Ende des Einschubs sieht, ohne ihn
dafür komplett lesen zu müssen.
Eine gute Idee, doch ich fürchte, dass gerade das
Zielpublikum sich auch für die zusätzlichen
Erläuterungen interessieren wird.

Eben. Deshalb möchte ich ihnen durch reine Betätigung
der Augen die Wahl zwischen beiden Lese-Modi lassen,
ohne erforderlichen Mausklick.
(Ich mache das übrigens seit ca. 2 Jahren bei allen
HTML-Dokumenten, die ich schreibe.)

Was hältst du von Fußnoten am Ende der Seite?

Siehe oben: Der Benutzer sieht nicht, wie wertvoll
der Inhalt für ihn ist oder auch nicht, klickt ggf.
auf Verdacht dorthin und unterbricht seinen Lesefluß.

Da ist mir der kleiner geschriebene Einschub lieber.

(Ein Grund mehr, keinen M$IE zu nehmen

• richtige Browser können ja drüber skalieren.
  ;-)
  Davon hat dich große Mehrheit leider wenig.

Wahr ... das ist das Gegenargument, deswegen ich
ja überhaupt darüber diskutiere.

Wie war das nochmal mit deiner Akzeptanz von
Monopolen? ;p

Ich finde mein Informationsmonopol auf dieser Seite
grohsartik. ;-)

Huch! Ein mailto-Link. Soll ich dir einen
Formmailer schreiben? ;p
Ich habe einen Form-Mailer auf meiner Domain
im Einsatz ... aber was spricht gegen einen
mailto-Link?
Er funktioniert leider nicht zuverlässig.

Unzuverlässig? Das wäre mir allerdings neu.

Daß er ggf. überhaupt nicht funktioniert, wenn der
Browser keinen Mail-Client enthält, damit kann ich
leben.
Das Ziel-Publikum von gzip_cnc sollte CGI-Skripte
installieren können - das sind keine Voll-DAUs.

Das ist kein Problem. Meine Baustelle
(http://www.skop.net/preview/)
sieht zwar in N4.x, IE und Opera/Mozilla
jeweils etwas anders aus, die Seite funktioniert
trotzdem überall.
Der alte Netsie versteht CSS durchaus, man muss
nur wissen, was man ihm zumuten kann.

Genau das zu lernen habe ich allerdings wenig Lust.
(Umso weniger, als Netscape 7 ja doch schneller auf
den Markt kommt, als ich verschiedentlich in diesem
Forum geschätzt hatte ...)

Einen Versuch ist es allemal wert, Unterstützung
ist hiermit zugesagt.

Danke, ich merke mir das Angebot.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Orlando,

Screenshot von N4.78: <img src="http://www.skop.net/self/gzip_cnc_n4.gif" border=0 alt="">

um noch mal gezielt auf diesen Fall einzugehen:

Ich habe inzwischen meine mod_gzip-Seiten praktisch
identisch umgestellt (die ursprünglich quer laufende
Link-Leiste läuft mir sonst demnächst über, und hori-
zontales Scrolling ist ja 'böse').

Und obwohl ich dort
    http://www.schroepl.net/projekte/mod_gzip/
glaube, dasselbe zu tun, schiebt sich hier _nicht_
das Bild über die Links, auch nicht in Netscape 4.

Falls mir bitte jemand den Unterschied erklären
könnte ...

Viele Grüße
      Michael

[Orlando]

Hi Michael,

Ich habe inzwischen meine mod_gzip-Seiten praktisch
identisch umgestellt (die ursprünglich quer laufende
Link-Leiste läuft mir sonst demnächst über, und hori-
zontales Scrolling ist ja 'böse').

kommt auf den Einsatzzweck an.

Und obwohl ich dort
http://www.schroepl.net/projekte/mod_gzip/
glaube, dasselbe zu tun, schiebt sich hier _nicht_
das Bild über die Links, auch nicht in Netscape 4.

Bei /mod_gzip hast du nach dem Bild noch <p> </p> und somit ein Block-Element eingebunden. Die Links werden dann unterhalb dargestellt. Das schafft auch bei /gzip_cnc Abhilfe (ist ungetestet, ich bin aber zuversichtlich).

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Orlando,

Bei /mod_gzip hast du nach dem Bild noch
<p> </p> und somit ein Block-Element eingebunden.

ja, einer der vielen verzweifelten Versuche beim
Kröten-Töten.

Die Links werden dann unterhalb dargestellt.
Das schafft auch bei /gzip_cnc Abhilfe (ist
ungetestet, ich bin aber zuversichtlich).

nope: http://www.schroepl.net/projekte/gzip_cnc/

Es verschiebt die nachfolgenden Zeilen in der Tat
etwas nach unten, aber nicht unterhalb des Bildes.

Viele Grüße
      Michael

[Orlando]

Hi Michael,

nach dem Bild noch <p> </p>
Die Links werden dann unterhalb dargestellt.

nope: http://www.schroepl.net/projekte/gzip_cnc/

Doch: <img src="http://www.skop.net/self/gzip_cnc_n4b.gif" border=0 alt="">

Es verschiebt die nachfolgenden Zeilen in der Tat
etwas nach unten, aber nicht unterhalb des Bildes.

Bei mir schon - und ich habe einen frisch Installierten 4.78. Liegt's vielleicht an deinen Einstellungen?

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Orlando]

Hi Michael,

Doch: <img src="http://www.skop.net/self/gzip_cnc_n4b.gif" border=0 alt="">

verstehst du jetzt, warum mir <small> manchmal zu klein ist? ;)

Pfff... Ok, du hörst diesbezüglich noch von mir.

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Orlando]

Hi Michael,

neues Spiel - neues Glück.

Die Links werden dann unterhalb dargestellt.

Ich konnte dem alten Herren dieses Missverständnis ausreden und musste dafür lediglich kleine Modifikationen *g* am Quelltext vornehmen. Am besten, du siehst es dir mal an (und teste bitte auch 'moderne' Browser) und sagst mir dann, was du davon hältst. Die wichtigen Stellen habe ich kommentiert.

http://www.skop.net/self/gzip_cnc/ :))))

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Orlando,

Ich konnte dem alten Herren dieses Missverständnis
ausreden und musste dafür lediglich kleine
Modifikationen *g* am Quelltext vornehmen.

sagtest Du "kleine"? Naja ... ;-)

Am besten, du siehst es dir mal an (und teste bitte
auch 'moderne' Browser)

Mozilla 1.0: Viel besser als meine Lösung.
Opera 6:     Identisch zu Mozilla.
M$IE 5.5:    Wie vorher (okay).
Netscape 4:  Viel besser - allerdings werden die beiden
             W3C-Buttons jetzt übereinander statt ne-
             beneinander gesetzt.

und sagst mir dann, was du davon hältst.

Großartig. Die immer sichtbare Navigation ist einfach
besser. Jetzt muß ich es bloß noch verstehen ...

Die wichtigen Stellen habe ich kommentiert.

Danke sehr - das hilft enorm.

Viele Grüße
      Michael

[Stefan Einspender]

Hallo Michael,

nach dem ich das Orlando-Problem [1] ja mittlerweile gelöst habe
(siehe <?m=78679&t=14094>), will ich noch einige Worte zu der über-
arbeiteten Version von Orlando loswerden, im Großen und Ganzen
scheint sie mir ok, aber an paar Details kann man da schon noch
feilen :-)

sagtest Du "kleine"? Naja ... ;-)

-> das div#nav sollte inkl. Inhalt ganz oben im Quelltext platziert
   werden, also noch über div#content
-> #nav p.active   durch   #nav p   ersetzen
-> .passive   durch   #nav a   ersetzen, falls notwendig noch die
   gerade aktive Seite über eine zusätzliche ID hervorheben
-> <div class="icon"> sollte vielleicht eher eine ID haben
-> .logo   durch   div#icon img   ersetzen (siehe vorhergehender Punkt)

Und dann natürlich schauen, wo welche Klasse oder ID noch weggelassen
werden kann. Ich weiß, es sind oft nur Kleinigkeiten, aber wenn schon
tolles CSS-Layout, dann auch richtig [2] ;-)

Viele Grüße,
Stefan

[1] Da ging es kurzgefasst darum, dass auf Favicon.de die CSS-Datei
    von Opera nicht erkannt wurde, weil er media="screen,print"
    nicht versteht, sollte jetzt funktionieren.
[2] Orlando's Variante ist wirklich gut und auch einsatzfähig, die
    paar Kleinigkeiten kann man aber noch verbessern. Insbesondere
    sollte man den unnötigen Einsatz von Klassen und ID's vermeiden.

[Michael Schröpl]

Hi Stefan,

-> das div#nav sollte inkl. Inhalt ganz oben im
   Quelltext platziert werden, also noch über
   div#content

warum?

Ich habe mir das auch überlegt, finde es aber so herum
sinnvoller. Denke auch an dumme Suchmaschinen, die
<meta description> nicht begreifen - denen gebe ich
lieber Inhalt am Dokument-Anfang als die Navigation.)

-> #nav p.active   durch   #nav p   ersetzen

Yep - habe ich rausgenommen.

-> .passive   durch   #nav a   ersetzen,

Auch. (Prima, es wird immer weniger ...)

falls notwendig noch die gerade aktive Seite
   über eine zusätzliche ID hervorheben

Die zeichnet sich gerade durch den Unterschied zwischen
<p> und <a> aus - das reicht.

-> <div class="icon"> sollte vielleicht eher eine
   ID haben

Yep, und die Mail-Adresse ebenfalls.

-> .logo   durch   div#icon img   ersetzen (siehe
   vorhergehender Punkt)

In meinem Kontext reichte sogar "#icon img" ...

Und dann natürlich schauen, wo welche Klasse oder
ID noch weggelassen werden kann.
Ich weiß, es sind oft nur Kleinigkeiten, aber wenn
schon tolles CSS-Layout, dann auch richtig [2] ;-)

»»

[2] Orlando's Variante ist wirklich gut und auch
    einsatzfähig, die paar Kleinigkeiten kann man
    aber noch verbessern. Insbesondere sollte man
    den unnötigen Einsatz von Klassen und ID's
    vermeiden.

Full Ack.

Es geht immerhin um Komprimierung auf diesen Seiten ...
jedes Byte, das nicht existiert, muß auch nicht ge-
zippt werden ... :-)

Ich glaube, diese Aktion hat mir die Augen geöffnet,
auch wenn ich von der Syntax her noch ein paar Dinge
nicht wirklich begreife ... (etwa das "body > #nav")

Vielen Dank für die vielen guten Tips!
       Michael

[Stefan Einspender]

Hallo Michael,

-> das div#nav sollte inkl. Inhalt ganz oben im
   Quelltext platziert werden, also noch über
   div#content

warum?

den Grund, warum ich es so sinnvoller finde, hast Du ja bereits
selbst erkannt. Eben, dass man ohne CSS die Navigation nicht erst
unten auf der Seite findet. Vielleicht baust Du einfach etwas wie
<a href="#navigation" style="display:none;">Navigation</a> ein
oder eben lässt es so, wie es jetzt ist ;-)

falls notwendig noch die gerade aktive Seite
   über eine zusätzliche ID hervorheben

Die zeichnet sich gerade durch den Unterschied zwischen
<p> und <a> aus - das reicht.

Eine Idee wäre auch, grundsätzlich alle Links in der Navigation
auch als solche umzusetzen, nur eben die gerade aktuelle Seite
mit <a id="active" href="#anfang">Versionen</a> zu versehen und
a#active über css wie gewünscht formatieren. Dann spart man den
Absatz (der strenggenommen innerhalb der Navi nicht sinnsoll ist)
und hat trotzdem die momentane optische Hervorhebung der aktiven
Seite.

Ich glaube, diese Aktion hat mir die Augen geöffnet,
auch wenn ich von der Syntax her noch ein paar Dinge
nicht wirklich begreife ... (etwa das "body > #nav")

unser aller geliebter MSIE (*hüstel*) ist leider nicht in der
Lage, um Sachen die er nicht kapiert, einfach einen großen Bogen
zu machen, nein, man muß ihn wirklich nochmal ausschließen. Mit
body > #nav spricht man einfach alle Elemente mit der ID #nav
innerhalb des body-Bereiches an und weist ihnen dann, in diesem
Fall, position:fixed; zu. Der MSIE scheitert an diesem Selektor.

Soweit erstmal, bei weiteren Fragen stehe ich gern zur Verfügung :-)

Viele Grüße,
Stefan

[Michael Schröpl]

Hi Stefan,

Eben, dass man ohne CSS die Navigation nicht erst
unten auf der Seite findet.

hm ... das ist ein Argument.
Benutzer ohne CSS gibt es wahrscheinlich mehr als
Suchmaschinen ohne <meta description>-Interpretation.

Okay - gekauft.

falls notwendig noch die gerade aktive Seite
   über eine zusätzliche ID hervorheben
Die zeichnet sich gerade durch den Unterschied zwischen
<p> und <a> aus - das reicht.
Eine Idee wäre auch, grundsätzlich alle Links in
der Navigation auch als solche umzusetzen, nur eben
die gerade aktuelle Seite mit <a id="active"
href="#anfang">Versionen</a> zu versehen und
a#active über css wie gewünscht formatieren.

Optisch, ja. Aber ich möchte keinen Link anbieten, bei
dem man durch Draufklicken den aktuellen Zustand nicht
ändert. Das halte ich für Verarschung des Besuchers.

Dann spart man den Absatz (der strenggenommen
innerhalb der Navi nicht sinnvoll ist)

Ursprünglich hatte ich an dieser Stelle sogar <div>
drin - nicht zur Positionierung, sondern weil ich eben
irgend einen Container brauchte.

auch wenn ich von der Syntax her noch ein paar
Dinge nicht wirklich begreife ... (etwa das
"body > #nav")
Mit body > #nav spricht man einfach alle Elemente
mit der ID #nav innerhalb des body-Bereiches an

Äh, tue ich das nicht (auch) mit
    body #nav
?
Ich kenne einfach diesen Selektor nicht ...

Soweit erstmal, bei weiteren Fragen stehe ich gern
zur Verfügung :-)

Wovon ich sofort Gebrauch mache.

Vielen Dank für die Hilfe - das wird Folgen haben ...
       Michael

[Michael Schröpl]

Vielen Dank für die Hilfe - das wird Folgen haben ...

http://www.schroepl.net/projekte/gzip_cnc/changes.htm#credits

... recht so?

Michael

[Stefan Einspender]

Hallo Michael,

http://www.schroepl.net/projekte/gzip_cnc/changes.htm#credits
... recht so?

danke :-)

Und hier noch ganz kurz der Unterschied zwischen den beiden von Dir
angesprochenen Selektoren:

body > div#nav
damit sprichst Du das DIV mit der ID #nav an, sofern es sich dabei
um ein Kind des body-Elementes handelt. D.h. dieses DIV darf nicht
innerhalb eines weiteren DIV's oder etwa in einer Tabelle stehen.

body div#nav
das DIV mit der ID #nav ist ein "Nachkomme" des body-Elementes, d.h.
es muß sich lediglich irgendwo zwischen dem öffnenden und dem schl.
body-Tag befinden

Im vorliegenden Fall ist der Unterschied tatsächlich egal, auch
#nav { [CSS-Definitionen] }
hätte ja bereits ausgereicht. Der Grund, warum > verwendet wird,
ist ganz einfach, weil der MSIE genau diesen Selektor nicht ver-
steht. In SELFHTML finden sich nur spärliche Informationen zu den
möglichen CSS-Selektoren, deshalb empfehle ich Dir bei Interesse
einen Blick in die W3C-Spezifikation zu CSS2:
http://www.w3.org/TR/REC-CSS2/selector.html

Viele Grüße,
Stefan

[Zapp]

Hallo Stefan,

body > div#nav
(...)
Der Grund, warum > verwendet wird, ist ganz einfach, weil der MSIE genau diesen Selektor nicht versteht.

Besser wäre: body>div#nav

Siehe: http://pixels.pixelpark.com/~koch/hide_css_from_browsers/child/: "Note: There must not be white space around the '>' ... "

In meinem IE5.0 macht das nämlich den entscheidenden Unterschied. Zu empfehlen ist es deshalb auch für favicon.de.

Grüße, Stefan

[Stefan Einspender]

Hallo Stefan,

Besser wäre: body>div#nav

Siehe: http://pixels.pixelpark.com/~koch/hide_css_from_browsers/child/: "Note: There must not be white space around the '>' ... "

hm ... <bei http://www.w3.org/TR/REC-CSS2/selector.html#child-selectors>
steht "Notice that the optional whitespace ..."
                       ^^^^^^^^^^^^^^^^^^^

In meinem IE5.0 macht das nämlich den entscheidenden Unterschied. Zu empfehlen ist es deshalb auch für favicon.de.

gut, habe es jetzt mal weggemacht. Wäre froh, wenn Du mir weitere
eventuell noch vorhandene Fehler melden könntest, danke :-)

Viele Grüße,
Stefan

[Zapp]

Hallo Stefan,

hm ... <bei http://www.w3.org/TR/REC-CSS2/selector.html#child-selectors>
steht "Notice that the optional whitespace ..."
                       ^^^^^^^^^^^^^^^^^^^

Sicher, aber würde IE das verstehen, wäre es kein Instrument, um ihn auszuschließen. ;-)

gut, habe es jetzt mal weggemacht. Wäre froh, wenn Du mir weitere
eventuell noch vorhandene Fehler melden könntest, danke :-)

Nee, nun sieht's gut aus, mein IE ist zufrieden mit dir! :-)

Grüße, Stefan

[Orlando]

Hi Michael,

-> das div#nav sollte inkl. Inhalt ganz oben im
   Quelltext platziert werden, also noch über
   div#content

Ich habe mir das auch überlegt, finde es aber so herum
sinnvoller. Denke auch an dumme Suchmaschinen, die
<meta description> nicht begreifen - denen gebe ich
lieber Inhalt am Dokument-Anfang als die Navigation.)

ich habe die Navigation bewusst an das Ende verschoben, weil ich es bei deaktivierten Stylesheets lieber habe, gleich an den eigentlichen Inhalt zu gelangen. Ich denke dabei auch an Leute, die zB mit einem Screenreader unterwegs sind. Ich stelle es mir lästig vor, am Beginn dauernd das gleiche vorgesetzt zu bekommen. Aber einen Anker-Verweis auf die ID der Navigation könnte man durchaus noch einbauen. Mit dem Haken, dass N4 ID-Anker (ohne name="...") ignoriert.

-> #nav p.active durch #nav p ersetzen
-> .passive durch #nav a ersetzen,

ACK

falls notwendig noch die gerade aktive Seite
   über eine zusätzliche ID hervorheben

Die zeichnet sich gerade durch den Unterschied zwischen
<p> und <a> aus - das reicht.

Sehe ich auch so.

-> <div class="icon"> sollte vielleicht eher eine
   ID haben

Yep, und die Mail-Adresse ebenfalls.

Ja, das ist die bessere Wahl. Eindeutigen Bereichen sollte man eine ID verpassen, wiederkehrenden Formatierungen Klassen.

-> .logo   durch   div#icon img   ersetzen

In meinem Kontext reichte sogar "#icon img" ...

Korrekt.

Und dann natürlich schauen, wo welche Klasse oder
ID noch weggelassen werden kann.

Zunächst ist das Stylesheet auszulagern, damit es nicht jedesmal mit übertragen werden muss. Dann sind mir noch redundante Farbangaben aufgefallen. Wenn im Body die Schriftfarbe Schwarz definiert ist, kann man diese bei den DIVs und Klassen weglassen. Lediglich abweichende Bereiche und zB <A> erhalten eine Farbdefinition. Wenn wir schon beim Byte-hamstern sind: #rrggbb -> #rgb (http://www.w3.org/TR/2001/WD-css3-color-20010305#numerical). Jetzt werden wir kleinlich ;)

[2] Orlando's Variante ist wirklich gut und auch
    einsatzfähig, die paar Kleinigkeiten kann man
    aber noch verbessern. Insbesondere sollte man
    den unnötigen Einsatz von Klassen und ID's
    vermeiden.

Ich hoffe, es ist entschuldbar, dass sich gestern keine perfekte Umsetzung ausgegangen ist ;) Auch wollte ich den Quelltext nicht so arg optimieren, dass die Änderungen nicht mehr gut nachvollziehbar sind.

Es geht immerhin um Komprimierung auf diesen Seiten ...
jedes Byte, das nicht existiert, muß auch nicht ge-
zippt werden ... :-)

Mit deinem/eurem Werk unterstützt du/ihr doch nur die Faulsäcke, die ihren Code nicht optimieren. Also sowas... *scnr*

Ich glaube, diese Aktion hat mir die Augen geöffnet,
auch wenn ich von der Syntax her noch ein paar Dinge
nicht wirklich begreife ... (etwa das "body > #nav")

http://www.w3.org/TR/REC-CSS2/selector.html
http://www.w3.org/TR/css3-selectors/

Der genannte Selektor ist hervorragend geeignet, Definitionen vor dem IE zu schützen - eher aber umgekehrt :)

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Orlando,

ich habe die Navigation bewusst an das Ende ver-
schoben, weil ich es bei deaktivierten Stylesheets
lieber habe, gleich an den eigentlichen Inhalt zu
gelangen.
Ich denke dabei auch an Leute, die zB mit einem
Screenreader unterwegs sind. Ich stelle es mir
lästig vor, am Beginn dauernd das gleiche vorgesetzt
zu bekommen.

hm ... da ist allerdings auch etwas dran. Stefans
Argumentation hat jedoch ebenfalls etwas für sich.
Was mache ich nun?

Beim Ansehen meiner Seiten über mein 33.6er-Modem habe
ich den Eindruck gewonnen, daß es schöner aussieht,
wenn die Navigation vorne in der Datei drin ist.
Denn ist sie hinten drin und das Dokument ist eines
der längeren, dann sieht man die "Einblendung" der
Navigation im Browser-Fenster mit einiger Verzögerung
recht deutlich. Anders herum ist sie sofort da - das
gefällt mir besser.

Aber einen Anker-Verweis auf die ID der Navigation
könnte man durchaus noch einbauen. Mit dem Haken,
dass N4 ID-Anker (ohne name="...") ignoriert.

Eben. Ich tue Netscape 4 mit Links auf "id" weh - und
Netscape 4 mit abgeschaltetem CSS wäre einer der wahr-
scheinlichsten Kandidaten dafür, diesen Link jemals
zu sehen. Dann lieber nicht.

Eindeutigen Bereichen sollte man eine ID verpassen,
wiederkehrenden Formatierungen Klassen.

An diese Philosopie gewöhne ich mich auch gerade.
Wobei ich noch nicht verstanden habe, was so schlimm
daran sein soll, Unikate auch mal direkt "inline" zu
formatieren ...

Zunächst ist das Stylesheet auszulagern, damit es
nicht jedesmal mit übertragen werden muss.

Auch für Dich: Ich _will_, daß es jedesmal mit über-
tragen wird. Das kostet _weniger_ Bandbreite! Rechne
es ruhig mal selbst durch ...

Dann sind mir noch redundante Farbangaben aufge-
fallen.

Tja, wenn die alle redundant wären ...

Wenn im Body die Schriftfarbe Schwarz definiert ist,
kann man diese bei den DIVs und Klassen weglassen.

Nicht, wenn man warning-frei gegen den W3C-CSS-Checker
validieren will.

Wenn wir schon beim Byte-hamstern sind: #rrggbb ->
#rgb
(http://www.w3.org/TR/2001/WD-css3-color-20010305#numerical).
Jetzt werden wir kleinlich ;)

Hoppla! :-) Hm ... die Lesbarkeit erhöht das ja nicht
gerade ... ich überlege mir das mal.

Ich hoffe, es ist entschuldbar, dass sich gestern
keine perfekte Umsetzung ausgegangen ist ;)
Auch wollte ich den Quelltext nicht so arg opti-
mieren, dass die Änderungen nicht mehr gut nach-
vollziehbar sind.

Deine Methode war exakt optimal für mich!
Die Änderungen waren so gut kommentiert, daß ich sie
nachvollziehen und in meine im Detail völlig anders
strukturierten SSI-Include-Dateien einbauen konnte.

Jetzt, nachdem wir die große Operation hinter uns
haben - falls Du noch Details optimieren möchtest,
nur zu ...

Mit deinem/eurem Werk unterstützt du/ihr doch nur
die Faulsäcke, die ihren Code nicht optimieren.
Also sowas... *scnr*

Keineswegs. Komprimiere mal Deine eigenen Seiten damit!

Der genannte Selektor ist hervorragend geeignet,
Definitionen vor dem IE zu schützen - eher aber
umgekehrt :)

Und genau diese "Denke" ist der Grund, weshalb ich
solche Technologien bisher ganz bewußt nicht eingesetzt
habe. Ich möchte nicht gegen die Bugs der Hersteller
programmieren - ich möchte echte Probleme lösen.

Du und Stefan, ihr habt Euch einen Link in der "Credits"-Abteilung von gzip_cnc redlich verdient ...
worauf (URL, Text/Name) möchtest Du den gerne haben?

Vielen Dank!
       Michael

[Orlando]

Hi Michael,

ich habe die Navigation bewusst an das Ende ver-
schoben,

Stefans Argumentation hat jedoch ebenfalls etwas für
sich. Was mache ich nun?

belasse die Navigation oben, es sind ja nur einige Links. Mich stört so etwas nur, wenn auf jeder Seite eine vollständige Sitemap mit _zahlreichen_ Links vorhanden ist - im schlimmsten Fall durch <p> auf viele Zeilen verteilt. Das haben wir ja mit display:block elegant umschifft.

Anker-Verweis auf die ID der Navigation / N4

hat sich damit erledigt.

Eindeutigen Bereichen sollte man eine ID verpassen,
wiederkehrenden Formatierungen Klassen.

An diese Philosopie gewöhne ich mich auch gerade.
Wobei ich noch nicht verstanden habe, was so schlimm
daran sein soll, Unikate auch mal direkt "inline" zu
formatieren ...

Wenn es sich tatsächlich um ein Unikat handelt, ist das nicht verwerflich. Anders sieht es aus, wenn du ein 'Unikat pro Seite' meinst. Dann brächte die externe Definition wiederum Vorteile. Dass ich soetwas nicht mache, hat einen einfachen Grund: Ich will alles an einer Stelle haben. Übrigens kannst du einem Element durchaus mehrere Klassen gleichzeitig zuweisen, zB <p class="klein rot">, falls das für dich relevant ist.

Zunächst ist das Stylesheet auszulagern, damit es
nicht jedesmal mit übertragen werden muss.

Auch für Dich: Ich _will_, daß es jedesmal mit über-
tragen wird. Das kostet _weniger_ Bandbreite!

Wieder was dazugelernt, danke :)

Dann sind mir noch redundante Farbangaben aufge-
fallen.

Tja, wenn die alle redundant wären ...

Stimmt, das hatte ich übersehen.

Wenn im Body die Schriftfarbe Schwarz definiert ist,
kann man diese bei den DIVs und Klassen weglassen.

Nicht, wenn man warning-frei gegen den W3C-CSS-Checker
validieren will.

Ich wollte damit sagen, dass es keinen Sinn hat, eine Farbkombination, die gleichlautend bereits für body{} definiert wurde, bei einer Klasse/ID, die sich im Body befindet und durch kein umgebendes Element anders definiert wurde, nochmals anzugeben. Wenn Vorder- oder Hintergrund abweichen, muss natürlich auch der Gegenpart neu definiert werden, damit der Vali nicht meckert.

#rrggbb -> #rgb

Hoppla! :-) Hm ... die Lesbarkeit erhöht das ja nicht
gerade ... ich überlege mir das mal.

Kommt darauf an, ob du wirklich den gesamten Farbraum ausnützen willst oder musst. Ich komme mit der dreistelligen Angabe eigentlich immer aus und finde sie auch übersichtlicher.

Deine Methode war exakt optimal für mich!
Die Änderungen waren so gut kommentiert, daß ich sie
nachvollziehen und in meine im Detail völlig anders
strukturierten SSI-Include-Dateien einbauen konnte.

Freut mich, das zu hören! Ich hatte mir nämlich überlegt, wie ich dich wohl am besten 'missionieren' könnte - versenkt! ;D

Jetzt, nachdem wir die große Operation hinter uns
haben - falls Du noch Details optimieren möchtest,
nur zu ...

Viel ist da dank Stefans Hinweisen nicht mehr zu machen, allerdings möchte ich dir noch vorschlagen, die Navigation beim Ausdruck der Seite auszublenden. Sieh' dir mal </archiv/2002/5/12547/#m69517> und speziell http://selfhtml.teamone.de/css/formate/einbinden.htm#media an. Ich denke, das wirst du bestimmt haben wollen.

Mit deinem/eurem Werk unterstützt du/ihr doch nur
die Faulsäcke, die ihren Code nicht optimieren.
Also sowas... *scnr*

Keineswegs. Komprimiere mal Deine eigenen Seiten damit!

Das war natürlich nicht ernst gemeint - du weißt allerdings nicht, was du mir da vorschlägst - reden wir in einigen Monaten nochmal darüber ;)

Der genannte Selektor ist hervorragend geeignet,
Definitionen vor dem IE zu schützen - eher aber
umgekehrt :)

Und genau diese "Denke" ist der Grund, weshalb ich
solche Technologien bisher ganz bewußt nicht eingesetzt
habe. Ich möchte nicht gegen die Bugs der Hersteller
programmieren - ich möchte echte Probleme lösen.

Ja, aber das nützt in diesem speziellen Fall überhaupt nichts. Der IE ist nunmal nicht nur für position:fixed zu blöd, nein, er verschiebt die so definierten Bereiche auch noch unvorhersehbar. Da ich dieses Art der Positionierung aber unbedingt haben will, muss ich diesen Kniff anwenden. Den alten Netscape vor aufwendigen Stylesheets mit @import zu schützen ist ja nichts anderes. Mal von dessen Erscheinungsdatum abgesehen...

Du und Stefan, ihr habt Euch einen Link in der "Credits"-Abteilung von gzip_cnc redlich verdient ...
worauf (URL, Text/Name) möchtest Du den gerne haben?

Oh, danke - passt schon perfekt :)

Vielen Dank!

Deswegen sind wir letztendlich hier - gern' geschehen und auch von mir ein Dankeschön an Stefan.

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Orlando,

Wenn es sich tatsächlich um ein Unikat handelt, ist das nicht
verwerflich. Anders sieht es aus, wenn du ein 'Unikat pro Seite'
meinst. Dann brächte die externe Definition wiederum Vorteile.

in diesem Fall ist es ein Unikat, das pro Seite via SSI eingebunden
wird ... den Quelltext gibt es nur einmal. Da war es halt verlockend

• ich wollte alle relevanten Informationen an einer Stelle haben.

Übrigens kannst du einem Element durchaus mehrere Klassen gleichzeitig
zuweisen, zB <p class="klein rot">, falls das für dich relevant ist.

Mit welchen *#*@§$&% UserAgents funktioniert das doch gleich wieder nicht?

Ich wollte damit sagen, dass es keinen Sinn hat, eine Farbkombination,
die gleichlautend bereits für body{} definiert wurde, bei einer
Klasse/ID, die sich im Body befindet und durch kein umgebendes Element
anders definiert wurde, nochmals anzugeben.

Ich hoffe, das habe ich auch nicht getan.

Wenn Vorder- oder Hintergrund abweichen, muss natürlich auch der
Gegenpart neu definiert werden, damit der Vali nicht meckert.

Dies hingegen reichlich ... und ich mag den Vali.

#rrggbb -> #rgb
Hoppla! :-) Hm ... die Lesbarkeit erhöht das ja nicht
gerade ... ich überlege mir das mal.
Kommt darauf an, ob du wirklich den gesamten Farbraum ausnützen willst
oder musst. Ich komme mit der dreistelligen Angabe eigentlich immer
aus und finde sie auch übersichtlicher.

Ich verwende aus Tradition nur Netscape-Farben, deshalb habe ich jetzt
fast alles umgestellt.
Die einzige sechsstellige Farbe, die noch drin ist, ist die Hintergrund-
farbe von <body>, mit der ich das Aussehen von bg.jpg zu emulieren versuche.

Äh, bevor ich es vergesse: Welche Browser verstehen diese 3er-Farbcodes?
(Ich habe noch ein paar Dutzend andere CSS-Dateien in meiner Domain - aber
bevor ich da mit der Heckenschere dran gehe ...)

Ich hatte mir nämlich überlegt, wie ich dich wohl am besten
'missionieren' könnte - versenkt! ;D

In der Tat - das am lebenden Beispiel zu sehen, war optimal.
Als nächstes werde ich mir die mod_gzip-Seiten vornehmen ...

die Navigation beim Ausdruck der Seite auszublenden.

Au ja - das ist eine gute Idee.

Sieh' dir mal </archiv/2002/5/12547/#m69517> und speziell
http://selfhtml.teamone.de/css/formate/einbinden.htm#media

Das verwende ich bereits an anderer Stelle:
    http://www.schroepl.net/ms.css
(Meine pbm-Seiten sind gleichzeitig Druckvorlagen für ein Heft
 - und _dort_ müssen sie strikt schwarz-weiß sein.)

Mit deinem/eurem Werk unterstützt du/ihr doch nur
die Faulsäcke, die ihren Code nicht optimieren.
Also sowas... *scnr*
Keineswegs. Komprimiere mal Deine eigenen Seiten damit!
Das war natürlich nicht ernst gemeint - du weißt allerdings nicht,
was du mir da vorschlägst

Doch - ich hätte gerne Testflieger für mein gzip_cnc ...
irgendwer muß doch auch meine Formulierungen korrekturlesen. ;-)

Und genau diese "Denke" ist der Grund, weshalb ich
solche Technologien bisher ganz bewußt nicht eingesetzt
habe. Ich möchte nicht gegen die Bugs der Hersteller
programmieren - ich möchte echte Probleme lösen.
Da ich dieses Art der Positionierung aber unbedingt haben will,
muss ich diesen Kniff anwenden.
Den alten Netscape vor aufwendigen Stylesheets mit @import zu schützen
ist ja nichts anderes. Mal von dessen Erscheinungsdatum abgesehen...

Ja, okay. Aber ich mag eben diese "Mängelverwaltung" nicht, bei Verwendung
von Features, die jeder UserAgent anders umsetzt.
Deshalb verwende ich kein JavaScript und kein CSS, wenn es nicht sein muß.
Bei Apache, Perl, SQL, UNIX-Kommandos etc. weiß ich, daß ich mich darauf
_verlassen_ kann, daß es funktioniert ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.ico" border=0 alt=""> Michael

[Orlando]

Hi Michael,

Übrigens kannst du einem Element durchaus mehrere Klassen gleichzeitig
zuweisen, zB <p class="klein rot">, falls das für dich relevant ist.

Mit welchen *#*@§$&% UserAgents funktioniert das doch gleich wieder nicht?

das sollte keine Probleme machen, ist seit HTML4.0 vorgesehen. http://www.w3.org/TR/1998/REC-html40-19980424/struct/global.html#h-7.5.2 sagt:

class = cdata-list [CS]
  This attribute assigns a class name or set of class names to an element.

Wenn Vorder- oder Hintergrund abweichen, muss natürlich auch der
Gegenpart neu definiert werden, damit der Vali nicht meckert.

Dies hingegen reichlich ... und ich mag den Vali.

Schließlich hat er auch Recht ;)

#rrggbb -> #rgb

Äh, bevor ich es vergesse: Welche Browser verstehen diese 3er-Farbcodes?

Naja, es ist schon seit CSS1 spezifiziert. Zitat aus http://www.w3.org/TR/REC-CSS1#color-units:

This makes sure that white (#ffffff) can be specified with the
  short notation (#fff) and removes any dependencies on the color
  depth of the display.

Wenn ich von einer geringen Farbtiefe auf eine altes System und einen alten Browser schließe, ist es also sogar zu empfehlen.

(Ich habe noch ein paar Dutzend andere CSS-Dateien in meiner Domain - aber
bevor ich da mit der Heckenschere dran gehe ...)

Weg mit den alten Zöpfen ;)

Ich hatte mir nämlich überlegt, wie ich dich wohl am besten
'missionieren' könnte - versenkt! ;D

In der Tat - das am lebenden Beispiel zu sehen, war optimal.
Als nächstes werde ich mir die mod_gzip-Seiten vornehmen ...

Habe ich mir gerade angesehen, sieht _sehr gut_ aus. Valide, keine Fehler, keine Warnungen und sogar schon optisch etwas aufgemotzt. Toll! Wenn du nicht aufpasst, wirst du noch zum CSS-Prediger. Das freut mich natürlich besonders ;)

die Navigation beim Ausdruck der Seite auszublenden.

Das verwende ich bereits an anderer Stelle:

Perfekt.

Doch - ich hätte gerne Testflieger für mein gzip_cnc ...
irgendwer muß doch auch meine Formulierungen korrekturlesen. ;-)

Ok, am Sonntag stelle ich mich als Crashtest-Dummerchen zur Verfügung. Man darf gespannt sein...

Ja, okay. Aber ich mag eben diese "Mängelverwaltung" nicht, bei Verwendung
von Features, die jeder UserAgent anders umsetzt.

Ja, aber es gibt keine vernünftige Alternative.

Deshalb verwende ich kein JavaScript und kein CSS, wenn es nicht sein muß.

Javascript: ACK, aber CSS ist IMHO nicht so anspruchsvoll. Ein paar wenige Tricks und regelmäßige Tests mit allen Browsern helfen.

Bei Apache, Perl, SQL, UNIX-Kommandos etc. weiß ich, daß ich mich darauf
_verlassen_ kann, daß es funktioniert ...

Ein Server äußert sich auch ziemlich unmissverständlich, wenn ihm etwas nicht passt und versucht nicht, sich aus der Misere herauszuinterpretieren und seine Daten ungefragt _irgendwohin_ zu schreiben ;)

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Orlando,

Übrigens kannst du einem Element durchaus mehrere Klassen gleichzeitig
zuweisen, zB <p class="klein rot">, falls das für dich relevant ist.
Mit welchen *#*@§$&% UserAgents funktioniert das doch gleich wieder nicht?
das sollte keine Probleme machen

Und was ist mit der Kröte?

#rrggbb -> #rgb
Äh, bevor ich es vergesse: Welche Browser verstehen diese 3er-Farbcodes?
Naja, es ist schon seit CSS1 spezifiziert.

Das ist leider keine Antwort auf meine Frage ...

Wenn du nicht aufpasst, wirst du noch zum CSS-
Prediger.

Bestimmt nicht. "Anwender" reicht mir völlig.

Javascript: ACK, aber CSS ist IMHO nicht so
anspruchsvoll. Ein paar wenige Tricks und
regelmäßige Tests mit allen Browsern helfen.

Eben. Aber wie testet man mit _allen_ M$IE?

Vorhin habe ich nämlich eine Mail bekommen, daß die
bisherige Lösung mit M$IE 5.0 nicht funktioniert (mit
screenshot) ... ich habe nur einen 5.5 auf Win98.

Der freundliche Mail-Schreiber hat mir auch gleich
eine Änderung vorgeschlagen:

Die Lösung ist IMHO die:

#    body > #nav{position:fixed;}

ersetzen durch:

#    #nav[id]{position:fixed;}

Zumindest tut mein IE5.0 dann genau das, was er soll.

Hm ... bei meinen diversen Browsern macht das alles
keinen Unterschied ... nicht, daß ich mir unter "[id]"
irgendwas vorstellen könnte ...

Ich habe das jedenfalls mal eingebaut und hochgeladen.

Ein Server äußert sich auch ziemlich
unmissverständlich, wenn ihm etwas nicht passt
und versucht nicht, sich aus der Misere
herauszuinterpretieren und seine Daten ungefragt
_irgendwohin_ zu schreiben ;)

Eben. Ich liebe Server! Sie sind so "unkreativ". ;-)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Orlando]

Hi Michael,

<p class="klein rot">
Mit welchen *#*@§$&% UserAgents funktioniert das doch gleich wieder nicht?
das sollte keine Probleme machen
Und was ist mit der Kröte?

ok, das nächste Mal werde ich es vorher testen... Kröte 4 ist damit überfordert. :(

Wenn ich dir jetzt

<p class="rot"><span class="klein">rot klein</span></p>

vorschlage, wirfst du mir wohl die CSS-Angaben einzeln hinterher...

#rrggbb -> #rgb
Äh, bevor ich es vergesse: Welche Browser verstehen diese 3er-Farbcodes?
Naja, es ist schon seit CSS1 spezifiziert.
Das ist leider keine Antwort auf meine Frage ...

Wenigstens das kann N4. Getestet.

Aber wie testet man mit _allen_ M$IE?

Eine gute Frage. Dazu sind mehrere WinDozes nötig, aber wer tut sich das schon an? Ich jedenfalls nicht, ich teste nur mit dem 6er. Bei der Mangelhaftigkeit des IE ist die Versionsnummer schon egal, bei mir bekommt ein IE-Nutzer den gleichen Hinweis wie ein N4-Nutzer.

#    body > #nav{position:fixed;}

ersetzen durch:

#    #nav[id]{position:fixed;}

Zumindest tut mein IE5.0 dann genau das, was er soll.

Interessant, das war mir noch nicht bekannt.

Hm ... bei meinen diversen Browsern macht das alles
keinen Unterschied ... nicht, daß ich mir unter "[id]"
irgendwas vorstellen könnte ...

In diesen Klammern stehen attributbedingte Selektoren. Zitat http://www.w3.org/TR/css3-selectors/#selectors:

E[foo] -> an E element with a "foo" attribute

Somit wirkt der Selektor beim Element #nav, weil es ein Attribut namens 'id' besitzt.

Eben. Ich liebe Server! Sie sind so "unkreativ". ;-)

Ich finde sie irgendwie berechnend ;)

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Orlando,

neues Spiel - neues Glück.

eher: Nachher kein Spiel (ist eh nur England gegen
Nigeria) ... das war die Sache aber wert, denke ich.

Ich konnte dem alten Herren dieses Missverständnis
ausreden und musste dafür lediglich kleine
Modifikationen *g* am Quelltext vornehmen.

Ich glaube, in den vergangenen Stunden habe ich so
ziemlich jeden Fehler gemacht, den ich bei der Über-
tragung machen konnte. :-\

Gefunden habe ich vermutlich alle bis auf einen (vali-dieren gegen XHTML 1.1 hilft ... :-) - aber der läßt
den "alten Herrn" leider weiterhin störrisch reagieren.

Aktueller Stand meiner Bemühungen:
  http://www.schroepl.net/projekte/gzip_cnc_div/

Alle modernen Browser spielen wunderbar mit.

Was nicht funktioniert, ist genau das, wofür die
Änderung doch eigentlich gedacht war: Das Verhindern
des Nicht-Umbruchs der einzelnen Navigations-Einträge.
Netscape 4 ordnet die <a>s weiterhin als Fließtext an.

Eigentlich denke ich, mit

#nav p, #nav a:hover, #nav a
   {display:block; padding:3px; width:150px;
    font-size:15px; line-height:20px;}

sinngemäß das getan zu haben, was Orlando vorgeschlagen
hatte (inklusive Stefans Eliminierung aller Klassen-
namen). Allerdings scheint die Kröte das zu ignorieren.
Ich habe aber keine Ahnung, warum es nicht geht ...

Sobald dieses Problem gelöst ist, übernehme ich die
div-Variante auf die produktiven URLs.

Hoffnungsvoll,
      Michael

[Christian Kruse]

Hallo Michael,

Was nicht funktioniert, ist genau das, wofür die
Änderung doch eigentlich gedacht war: Das Verhindern
des Nicht-Umbruchs der einzelnen Navigations-Einträge.
Netscape 4 ordnet die <a>s weiterhin als Fließtext an.

Eigentlich denke ich, mit

#nav p, #nav a:hover, #nav a
   {display:block; padding:3px; width:150px;
    font-size:15px; line-height:20px;}

sinngemäß das getan zu haben, was Orlando vorgeschlagen
hatte (inklusive Stefans Eliminierung aller Klassen-
namen). Allerdings scheint die Kröte das zu ignorieren.
Ich habe aber keine Ahnung, warum es nicht geht ...

Nun, der Netscape 4.x kann natuerlich noch keine Meta-Klassen (#nav p, #nav
a:hover, #nav a). Da genau so wenig wie 'display:block'.

Gruesse,
 CK

[Stefan Einspender]

Hallo Michael,

Was nicht funktioniert, ist genau das, wofür die
Änderung doch eigentlich gedacht war: Das Verhindern
des Nicht-Umbruchs der einzelnen Navigations-Einträge.

also wenn es virtuelle Schläge gibt, dann hast Du Dir jetzt paar
verdient ;-)

(Nimm es bitte nicht so ernst, ist nicht böse gemeint.)

Ich probiere und denke, dass kann es doch überhaupt nicht geben,
am Ende habe ich einfach aus Orlando's Variante die Navigations-
zeilen rauskopiert, trotzdem noch der Umbruch da drin :-(

Naja, jedenfalls bin ich dann auf die Ursache gestossen:

style="margin:20px 0px 10px 0px;"

genau diesen Teil bitte da rausnehmen und, wie es sich gehört, oben
bei den CSS-Definitionen mit reinschreiben:

#nav img { margin:20px 0px 10px 0px; }

Problem gelöst :-)

Übrigens wäre es jetzt, da die Sache doch schon ganz gut klappt,
wohl an der Zeit, die ganzen CSS-Sachen in eine externe Datei zu
schreiben und die in den HTML-Dateien nur zu referenzieren. Da
mußt Du aufpassen, dass Netscape 4 nicht ausser vor bleibt, weil
eigentlich zeigt er ja jetzt alles soweit ganz gut an.
Schön ist es auch, wenn Du in dem link-Element einen title für
Dein Stylesheet vergibst, dann können Mozilla-Nutzer das Style-
sheet auswählen oder aber sich bei Bedarf die Sache ohne CSS
anzeigen lassen (View -> Use Style -> Basic Page Style).

Viele Grüße,
Stefan

[Michael Schröpl]

Hi Stefan,

also wenn es virtuelle Schläge gibt, dann hast Du
Dir jetzt paar verdient ;-)

wieso?

style="margin:20px 0px 10px 0px;"

Äh, ja und?
Weder der W3C-Validator für XHTML 1.1 noch der W3C-
Validator für CSS hatte daran etwas auszusetzen.
(Letzterer meldete noch nicht mal Warnings!)

genau diesen Teil bitte da rausnehmen und, wie es
sich gehört, oben bei den CSS-Definitionen mit
reinschreiben:

Wieso "gehört" es sich, eine externe Definition für
etwas zu schreibe, von dem ich genau weiß, daß ich es
nur an dieser einen Stelle brauchen werde?

#nav img { margin:20px 0px 10px 0px; }
Problem gelöst :-)

Und wieso das?

Verstehst Du jetzt, warum ich clientseitige Lösungen
_hasse_? Man macht "alles richtig", und irgend so ein
Müllprodukt versagt jämmerlich. (Wenn man halt auch
nicht alles selber programmiert ... gnlpfts.)

Übrigens wäre es jetzt, da die Sache doch schon
ganz gut klappt, wohl an der Zeit, die ganzen CSS-
Sachen in eine externe Datei zu schreiben

Du wirst lachen: Die stehen in einer externen Datei!
(Genauer gesagt sogar verteilt auf fünf solche Dateien.) Die werden allerdings via SSI eingebunden.

Die Seiten, die Du online siehst, sind das Ergebnis
eines Perl-Programmlaufes, der mit LWP::Simple diese
SSI-Dateien in statisches HTML "kompiliert" - nur so
kann ich sie ja mit gzip_cnc komprimiert ausliefern ...
mein Provider ist ja nicht bereit, mod_gzip zu instal-
lieren.
(Deshalb habe ich gzip_cnc ja überhaupt geschrieben!)

und die in den HTML-Dateien nur zu referenzieren.

Das mache ich absichtlich nicht.
Das ist doch gerade der Sinn der Sache: CSS-Informatio-
nen in der Datei selbst mitliefern, dort aber in kom-
primierter Form, geht viel schneller, als tausende von
sinnlosen HTTP-304-Responses ausliefern zu müssen, weil
DAUs ihre Browser nicht korrekt konfigurieren können.

Schön ist es auch, wenn Du in dem link-Element
einen title für Dein Stylesheet vergibst, dann
können Mozilla-Nutzer das Style-sheet auswählen

Hm ... also bei der momentanen Verbreitung von Mozilla
gebe ich mein Gesamtkonzept noch nicht nur für den auf.
Frag mich in einem Jahr nochmal ...

oder aber sich bei Bedarf die Sache ohne CSS
anzeigen lassen (View -> Use Style -> Basic Page
Style).

Wieso muß ich in meinen Dokumenten irgendwas tun, wenn
der Benutzer in seinen Preferences CSS abschalten kann?

Viele Grüße
      Michael

[Stefan Einspender]

Hallo Michael,

also wenn es virtuelle Schläge gibt, dann hast Du
Dir jetzt paar verdient ;-)

wieso?

ich war davon ausgegangen, dass Du den Entwurf von Orlando übernommen
und daran (nur) die von mir vorgeschlagenen Änderungen durchgeführt
hast. Es erschien mir immer eigenartiger, warum danach die Navigation
im NC4 nicht mehr untereinander steht. Also habe ich in mühevoller
Kleinarbeit nach und nach sämtliche CSS-Definitionen im Head-Bereich
rausgenommen bzw. wieder in Orlando's Variante geändert. Erst dann
habe ich bei Durchsicht des HTML-Teiles bemerkt, dass Du darin genau
die Änderung vorgenommen hast, welche in NC4 zu Problemen führt.
Naja und für diese Fehlersuche habe ich nicht gerade wenig Zeit ge-
braucht, weil ich einfach nicht davon ausgeganen bin, dass Du gerade
so eine folgenreiche Änderung nicht in den Head-Bereich schreibst :-/

style="margin:20px 0px 10px 0px;"

Äh, ja und?
Weder der W3C-Validator für XHTML 1.1 noch der W3C-
Validator für CSS hatte daran etwas auszusetzen.
(Letzterer meldete noch nicht mal Warnings!)

wir reden hier von einem Browser, dessen technische Basis mehr als
fünf Jahre alt ist und dessen CSS-Unterstützung mehr als dürftig
ist. Da führen eben auch solche scheinbar belanglosen Kleinigkeiten
zu nicht nachvollziehbaren Konsequenzen :-/

Wieso "gehört" es sich, eine externe Definition für
etwas zu schreibe, von dem ich genau weiß, daß ich es
nur an dieser einen Stelle brauchen werde?

es ist kein "Muß", aber imho ein sauberer Stil, wenn man den HTML-
und den CSS-Teil voneinander trennt. Ob einzelne Dateien notwendig
sind, ist je nach Einzelfall unterschiedlich. Welche Konsequenzen
es haben kann, wenn man es mal trennt, mal wieder nicht, habe ich
ja bereits oben geschildert.

#nav img { margin:20px 0px 10px 0px; }
Problem gelöst :-)

Und wieso das?

auch wenn die Antwort jetzt nicht unbedingt zielführend ist:
Das wissen vermutlich nur die Programmierer von NC4, der Browser
verhält sich oft scheinbar nach dem Zufallsprinzip.

Verstehst Du jetzt, warum ich clientseitige Lösungen
_hasse_? Man macht "alles richtig", und irgend so ein
Müllprodukt versagt jämmerlich. (Wenn man halt auch
nicht alles selber programmiert ... gnlpfts.)

Im Zweifelsfall, wenn der zu erwartende Mehraufwand relevant ist,
solltest Du Dir z.Bsp. überlegen, NC4 gänzlich von den CSS-Sachen
auszuschließen. Hier ging es ja gerade noch einmal gut ;-)

Du wirst lachen: Die stehen in einer externen Datei!
(Genauer gesagt sogar verteilt auf fünf solche Dateien.) Die werden allerdings via SSI eingebunden.

Stimmt, aber die Browser bekommen jeweils eine Datei inkl. CSS ge-
liefert und können so nicht die CSS-Datei in den Cache laden. Ich
finde die Trennung sinnvoller.

Das ist doch gerade der Sinn der Sache: CSS-Informatio-
nen in der Datei selbst mitliefern, dort aber in kom-
primierter Form, geht viel schneller, als tausende von
sinnlosen HTTP-304-Responses ausliefern zu müssen, weil
DAUs ihre Browser nicht korrekt konfigurieren können.

Ansichtssache, ich finde es einen unnötigen Overhead. Hier ist der
CSS-Teil nicht sooo umfangreich, aber ich habe schon CSS-Dateien
mit etlichen KB gehabt und da macht es schon einen Unterschied, ob
ich die in jeder HTML-Datei mitschicke oder nur einmal.

Hm ... also bei der momentanen Verbreitung von Mozilla
gebe ich mein Gesamtkonzept noch nicht nur für den auf.

Warum lag Dir dann soviel daran, dass die Navigation im NC4 nicht
nebeneinander steht? ;-)

Wieso muß ich in meinen Dokumenten irgendwas tun, wenn
der Benutzer in seinen Preferences CSS abschalten kann?

Die Abschaltung von CSS-Dateien auf einzelnen Seiten über den von
mir beschriebenen Weg geht sehr viel schneller als über die Ein-
stellungen im Browser und ist "mal eben auf die Schnelle" möglich.
Klar, bei Opera hat man dafür [STRG]+[G], bei Mozilla ist es eben
die genannte Vorgehensweise. Und es kann ja auch mal sein, dass Du
zusätzlich noch ein alternatives Stylesheet anbieten willst, da
mußt Du dann Namen für die Stylesheets vergeben und sie über das
link-Element einbinden.

Viele Grüße,
Stefan

[Michael Schröpl]

Hallo Stefan,

ich war davon ausgegangen, dass Du den Entwurf von
Orlando übernommen und daran (nur) die von mir
vorgeschlagenen Änderungen durchgeführt hast.

Daß (und warum) das nicht möglich war, habe ich ja
geschrieben.

weil ich einfach nicht davon ausgeganen bin, dass
Du gerade so eine folgenreiche Änderung nicht in
den Head-Bereich schreibst :-/

Vielleicht, weil es keinen vernünftigen Grund dafür
gab, anzunehmen, daß sie folgenreich sein könnte?
(Woher soll ich denn die Bugs von Netscape 4 kennen,
wenn ich zum ersten Mal in meinem Leben solche CSS-
Features einsetze?)

Im Zweifelsfall, wenn der zu erwartende Mehraufwand
relevant ist, solltest Du Dir z.Bsp. überlegen,
NC4 gänzlich von den CSS-Sachen auszuschließen.
Hier ging es ja gerade noch einmal gut ;-)

Bei meinem Tabellen-Layout ging es auch gut.

Du wirst lachen: Die stehen in einer externen
Datei! (Genauer gesagt sogar verteilt auf fünf
solche Dateien.) Die werden allerdings via SSI
eingebunden.
Stimmt, aber die Browser bekommen jeweils eine
Datei inkl. CSS geliefert und können so nicht die
CSS-Datei in den Cache laden. Ich finde die Trennung
sinnvoller.

Ich finde, den Browser geht es nichts an, in wie
vielen Stückchen er die Daten bekommt, die er zu
interpretieren hat.
Daß ich selbst aus Gründen der besseren Wartbarkeit
lokal getrennte CSS-Dateien für getrennte Aspekte der
Darstellung habe, ist meine Sache.

Ansichtssache, ich finde es einen unnötigen
Overhead.

Genau das Gegenteil ist der Fall: Die separaten CSS-
Dateien (und die dafür erforderlichen HTTP-Header)
sind der Overhead.

Hier ist der CSS-Teil nicht sooo umfangreich, aber
ich habe schon CSS-Dateien mit etlichen KB gehabt
und da macht es schon einen Unterschied, ob ich die
in jeder HTML-Datei mitschicke oder nur einmal.

Auch, wenn sie innerhalb des Dokuments komprimiert
werden können und als separate Dateien nicht?

Hm ... also bei der momentanen Verbreitung von
Mozilla gebe ich mein Gesamtkonzept noch nicht
nur für den auf.
Warum lag Dir dann soviel daran, dass die Navigation
im NC4 nicht nebeneinander steht? ;-)

Weil sie nicht schlechter aussehen durfte als bei
meinem Tabellen-Layout, natürlich. Du wolltest mich
davon überzeugen, daß es mit <div>s besser wird -
nicht "moderner, aber unbrauchbar für ...".

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Orlando]

Hi Michael,

(Woher soll ich denn die Bugs von Netscape 4 kennen,
wenn ich zum ersten Mal in meinem Leben solche CSS-
Features einsetze?)

die kann man aufgrund der Anzahl gar nicht alle kennen. @import und ein einfaches Stylesheet sind die Lösung, mehr Aufwand ist einfach nicht mehr gerechtfertigt.

NC4 gänzlich von den CSS-Sachen auszuschließen.
Hier ging es ja gerade noch einmal gut ;-)

Bei meinem Tabellen-Layout ging es auch gut.

Allerdings lässt sich das CSS-Layout bis auf 150% problemlos skalieren.

Stimmt, aber die Browser bekommen jeweils eine
Datei inkl. CSS geliefert und können so nicht die
CSS-Datei in den Cache laden. Ich finde die Trennung
sinnvoller.

Dachte ich auch immer, nur hatte ich nie an eine mögliche Kompression gedacht...

Genau das Gegenteil ist der Fall: Die separaten CSS-
Dateien (und die dafür erforderlichen HTTP-Header)
sind der Overhead.
Auch, wenn sie innerhalb des Dokuments komprimiert
werden können und als separate Dateien nicht?

Warum werden separate Dateien eigentlich nicht komprimiert ausgeliefert?

BTW, fällt mir gerade erst auf: ohne das Hintergrundbild gefällt mir die Site viel besser.

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Orlando,

@import und ein einfaches Stylesheet sind die
Lösung, mehr Aufwand ist einfach nicht mehr
gerechtfertigt.

dann kann ich die CSS-Definitionen halt nicht mehr
inlinen. (Gibt es nicht irgendwas Lokales, was die
Kröte nicht kann? z. B. @media ... wäre praktisch.)

Diese ganze Materie gehört m. E. dringend in die
neuen SelfHTML-Tipps&Tricks rein - bis SelfHTML in
vollem Umfange CSS abdecken wird, dürfte noch ein
Weilchen ins Land ziehen.

Bei meinem Tabellen-Layout ging es auch gut.
Allerdings lässt sich das CSS-Layout bis auf 150%
problemlos skalieren.

Also wenn ich bei Mozilla 1.0 nur ein einziges Mal per
Tastatur hochskaliere, werden bei mir die Navi-Einträge
schon zu breit.

Warum werden separate Dateien eigentlich nicht
komprimiert ausgeliefert?

Falls Du gzip_cnc meinst: Weil das Programm dazu wissen
müßte, welchen MIME-Typ es in "Content-Type" schreiben
müßte, und ich keine Lust hatte, an dieser Stelle die
Apache-Konfiguration nachzubilden.

Ansonsten: Die Kröte flippt aus, wenn sie CSS oder
JavaScript in komprimierter Form bekommt.
JavaScript ist auch bei M$IE ein Problem - beispiels-
weise feuert der onLoad-Event schon, wenn die Datei
auf dem Client ankommt, nicht erst, wenn sie erfolg-
reich dekomprimiert ist ...

BTW, fällt mir gerade erst auf: ohne das Hinter-
grundbild gefällt mir die Site viel besser.

Macht das echt so viel aus?
Ich habe es eigentlich deshalb heraus genommen, weil
ich per Hintergrundfarbe nahezu denselben Farbton
getroffen hatte und der Unterschied danach so marginal
war, daß ich glaubte, die Ladezeit für das Bild ein-
sparen zu wollen ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Stefan Einspender]

Hallo Michael,

dann kann ich die CSS-Definitionen halt nicht mehr
inlinen. (Gibt es nicht irgendwas Lokales, was die
Kröte nicht kann? z. B. @media ... wäre praktisch.)

schau Dir mal http://favicon.de/favicon.css an, vermutlich kannst
Du so NC4 ausschließen. Bei der hier besprochenen Website sehe ich
dafür allerdings keine Notwendigkeit, es sei denn, Du veränderst
wieder etwas, ohne die Folgen zu kennen ;-)

Diese ganze Materie gehört m. E. dringend in die
neuen SelfHTML-Tipps&Tricks rein - bis SelfHTML in
vollem Umfange CSS abdecken wird, dürfte noch ein
Weilchen ins Land ziehen.

wer denkt, dass er solch einen Beitrag im Bereich HTML oder CSS
leisten will, der kann gern mit mir Kontakt aufnehmen, ich werde
dann alle notwendigen Informationen zur Verfügung stellen. Eine
e-Mail an mailto:[e-mail] reicht zunächst aus.

Viele Grüße,
Stefan

[Michael Schröpl]

Hi Stefan,

Kröte nicht kann? z. B. @media ... wäre
praktisch.)
schau Dir mal http://favicon.de/favicon.css
an,

heißt das "ja" auf meine obige Frage?

es sei denn, Du veränderst wieder etwas, ohne die
Folgen zu kennen ;-)

Ich habe nichts "verändert". Dieses style-Attribut
stand bereits in der Original-Datei drin.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Stefan Einspender]

Hallo Michael,

Ansichtssache, ich finde es einen unnötigen
Overhead.

Genau das Gegenteil ist der Fall: Die separaten CSS-
Dateien (und die dafür erforderlichen HTTP-Header)
sind der Overhead.

die CSS-Datei zu SELFHTML 8.0 ist knapp 2 KB groß, wäre die jeweils
direkt in den HTML-Dateien eingebaut, dann wäre das Datenvolumenen
sicher höher als bei der jetztigen Variante. So groß sind die HTTP-
Header ja dann auch wieder nicht ;-)

In Deinem Fall funktioniert wohl die Komprimierung bei CSS-Dateien
nicht, was in diesem Einzelfall u.U. entscheidend sein kann. Allge-
mein dürfte die Trennung von HTML- und CSS-Dateien weniger Traffic
verursachen. Dazu kommt noch der nicht unwesentliche Punkt der
besseren Wartbarkeit. Bei der ersten Errata von SELFHTML wurde
u.a. die per CSS definierte Schriftgröße von 13px auf 13.4px ge-
ändert. Man stelle sich nur einmal vor, es hätte da keine externe
CSS-Datei gegeben ...

Auch, wenn sie innerhalb des Dokuments komprimiert
werden können und als separate Dateien nicht?

kann ich nicht beurteilen, da ich Deine Komprimierung nicht kenne.
Es *kann* durchaus sein, dass es im konkreten Fall sinnvoll ist,
HTML und CSS nicht zu trennen.

Weil sie nicht schlechter aussehen durfte als bei
meinem Tabellen-Layout, natürlich. Du wolltest mich
davon überzeugen, daß es mit <div>s besser wird -
nicht "moderner, aber unbrauchbar für ...".

ich denke nicht, dass http://www.webstandards.org/ im NC4 unbrauch-
bar ist. Wenn für Dich das Aussehen eines tabellenbasierten Layouts
in einem alten Browser das Maß der Dinge ist, dann würde ich dabei
(Tabellen) auch bleiben. Wenn Du dagegen die umfangreicheren Mög-
lichkeiten von CSS nutzen und Deine Dokumente nicht nur optisch,
sondern auch semantisch korrekt gestalten willst, dann wirst Du
nicht umhin kommen, zumindest mittelfristig ein einfacheres Aus-
sehen in alten Browsern zu akzeptieren.
Der wesentliche Unterschied liegt wohl darin, dass unbrauchbar
und modernes Aussehen zwei verschiedene Sachen sind. Tabellen-
layouts sind gerade in Hinblick auf aktuelle und zukünftige Ent-
wicklungen unbrauchbar, moderne Layouts sollten dieses Kriterium
nicht erfüllen, wenn sie wirklich gut sind.

Viele Grüße,
Stefan

[Michael Schröpl]

Hi Stefan,

Genau das Gegenteil ist der Fall: Die separaten CSS-
Dateien (und die dafür erforderlichen HTTP-Header)
sind der Overhead.
die CSS-Datei zu SELFHTML 8.0 ist knapp 2 KB groß, wäre die jeweils
direkt in den HTML-Dateien eingebaut, dann wäre das Datenvolumenen
sicher höher als bei der jetztigen Variante. So groß sind die HTTP-
Header ja dann auch wieder nicht ;-)

Fall 1: 2 KB CSS-Code, komprimierbar um etwa 60%,
da bleiben 800 Byte übrig - und _kein_ separater
HTTP-Zugriff.

Fall 2: Ein separater HTTP-Zugriff auf 2 KB nicht
komprimierbaren CSS-Code (wegen kaputter Browser,
die das nicht verstehen) kostet schon mal um die 1000
Bytes Verpackung (zwei HTTP-Header für Request und
Response plus TCP-Header).

Selbst wenn der Browser also lediglich prüfen würde,
ob die in seinem Cache vorliegende Datei aktuell ist,
würde das schon mehr kosten, als den CSS-Code immer
wieder komprimiert zu übertragen!
Und das setzt schon voraus, daß 100% aller Browser den
Cache an haben! Muß auch noch der unkomprimierte CSS-
Code öfters übertragen werden, dann ist die Verwendung
der separaten Datei natürlich noch schlechter.

Wenn sich also schon das Einbindung von 2 KB CSS-Code
lohnt, dann lohnt es sich bei den üblichen kleineren
Dateien umso mehr.

Allgemein dürfte die Trennung von HTML- und CSS-
Dateien weniger Traffic verursachen.

Ich behaupte nach wie vor das Gegenteil.

Dazu kommt noch der nicht unwesentliche Punkt der
besseren Wartbarkeit.

Der existiert nicht.
Ich verwende zur Wartung dieselben separaten CSS-
Dateien wie Du - ich liefere sie nur nicht separat aus.

Bei der ersten Errata von SELFHTML wurde
u.a. die per CSS definierte Schriftgröße von 13px
auf 13.4px geändert. Man stelle sich nur einmal vor,
es hätte da keine externe CSS-Datei gegeben ...

Meine statischen Dateien mit eingebundenem CSS-Code
entstehen natürlich durch ein Perl-Skript. Das kann
man ja mit ausliefern.

Wenn für Dich das Aussehen eines tabellenbasierten
Layouts in einem alten Browser das Maß der Dinge
ist, dann würde ich dabei (Tabellen) auch bleiben.

Nicht, wenn ich mit CSS dieselbe Qualität erreichen
kann (was mit Deiner und Orlandos Hilfe ja gelungen
ist).

Wenn Du dagegen die umfangreicheren Möglichkeiten
von CSS nutzen und Deine Dokumente nicht nur
optisch, sondern auch semantisch korrekt gestalten
willst, dann wirst Du nicht umhin kommen, zumindest
mittelfristig ein einfacheres Aussehen in alten
Browsern zu akzeptieren.

Das halte ich für nicht sinnvoll.

Ich möchte nicht die Qualität meines Angebots für
Benutzer reduzieren, nur um dadurch irgendwelchen
Normen zu genügen.
Ich verzichte nicht auf Funktionalität für Standards

• ich befolge aber Standards, wenn dies bei gleicher
  Funktionalität möglich ist.

Deshalb sind meine Dokumente zwar zum großen Teil XHTML
1.1 valide, aber mit vereinzelten target-Attributen.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Stefan Einspender]

Hallo Michael,

Selbst wenn der Browser also lediglich prüfen würde,
ob die in seinem Cache vorliegende Datei aktuell ist,
würde das schon mehr kosten, als den CSS-Code immer
wieder komprimiert zu übertragen!

*ähem* wir sprechen hier nicht von einer einzelnen Datei, sondern
von einer Website. Selbst wenn man es niedrig ansetzt, wird sich
ein Besucher wohl schon drei Seiten anschauen und da wird dann
genau einmal die CSS-Datei angefordert. Soll heißen, umso mehr
HTML-Dateien vom Besucher angefordert werden, die diese CSS-Datei
referenzieren, umso größer wird der Vorteil dieser Lösung. Dazu
kommt noch, dass eventuell nur ein 304 an den Browser geschickt
wird, wenn sie die CSS-Datei nicht verändert hat. Wenn also je-
mand 10 Seiten abruft, die ein und diesselbe CSS-Datei einbinden,
so werden später genau 11 Einträge im Logfile stehen.
Es kann natürlich sein, dass in Einzelfällen Browser so eigenartig
konfiguriert sind, dass sie zehnmal die CSS-Datei anfordern, aber
der Normalfall ist sowas nicht ;-)

Wenn sich also schon das Einbindung von 2 KB CSS-Code
lohnt, dann lohnt es sich bei den üblichen kleineren
Dateien umso mehr.

Wenn man mal Deine Komprierung ausser acht lässt, dann kann man
davon ausgehen, dass je weniger Seiten von einem Besucher im
Schnitt besucht werden und je kleiner die CSS-Datei ist, umso
mehr es sich lohnt, die CSS-Definitionen direkt in die HTML-
Dateien reinzuschreiben. Wenn eine oder beide Sache sich genau
andersrum verhalten, dann dürfte meine Variante die bessere Wahl
sein. Im konkreten Fall ist natürlich noch zu berücksichtigen,
dass Du einzelne CSS-Dateien unkomprimiert auslieferst, während
CSS direkt in HTML-Dateien mit komprimiert wird.

Allgemein dürfte die Trennung von HTML- und CSS-
Dateien weniger Traffic verursachen.

Ich behaupte nach wie vor das Gegenteil.

Wenn Du diese Behauptung pauschal aufstellst, dann ist sie falsch.
Wann welche Variante vermutlich besser geeignet ist, habe ich ja
weiter oben beschrieben. Auf http://de.selfhtml.org/ beispiels-
weise schauen die meisten Besucher etliche HTML-Seiten an, da
wäre es grober Unfug, die CSS-Definitionen jedesmal einzeln mit
reinzuschreiben. Eine externe CSS-Datei, die in fast allen Fällen
genau einmal während eines Besuches angefordert und geladen wird,
ist da sinnvoller.

Dazu kommt noch der nicht unwesentliche Punkt der
besseren Wartbarkeit.

Der existiert nicht.

im konkreten Fall kann es durchaus sein, dass er nicht existiert,
in der Regel ist er vorhanden. Die meisten Websites werden nicht
vollautomtisch über irgendwelche Scripte generiert, so dass es
schon einen Unterschied macht, ob man CSS-Änderungen in allen
HTML-Dokumenten oder nur in einer CSS-Datei vornehmen muß. CMS
lasse ich hier mal aussen vor, die können ja noch nicht einmal
validen Quelltext generieren, obwohl ein DOCTYPE angegeben ist :-/

Meine statischen Dateien mit eingebundenem CSS-Code
entstehen natürlich durch ein Perl-Skript. Das kann
man ja mit ausliefern.

im Fall einer Errata zu SELFHTML sicher nicht praktikal. Die CSS-
Datei von SELFHTML 8.0 wird in mehr als 400 HTML-Seiten genannt,
die hätte man dann allesamt mit der Errata austauschen müssen,
nur weil eine Kleinigkeit in der CSS-Definition geändert wurde,
die allerdings in allen HTML-Dateien notwendig ist (es war die
Standardschriftgröße).

Wenn Du dagegen die umfangreicheren Möglichkeiten
von CSS nutzen und Deine Dokumente nicht nur
optisch, sondern auch semantisch korrekt gestalten
willst, dann wirst Du nicht umhin kommen, zumindest
mittelfristig ein einfacheres Aussehen in alten
Browsern zu akzeptieren.

Das halte ich für nicht sinnvoll.

ich weiß, dass http://favicon.de im NC4 nicht wirklich schön aus-
sieht, aber es ist in diesem Browser vollständig nutzbar und des-
halb kann ich da ganz ruhig schlafen ;-)

Ich möchte nicht die Qualität meines Angebots für
Benutzer reduzieren, nur um dadurch irgendwelchen
Normen zu genügen.

die inhaltliche Qualität möchte ich wenn irgendwie möglich allen
Besuchern bieten. Um dieses Ziel zu erreichen (auch für Leute
die eine eigene Farbgestaltung benötigen), muß ich mich irgend-
wann von Sachen wie Tabellenlayout verabschieden. Wenn jemand
mit einem Screenreader daherkommt, soll er meine Seiten auch
vernünftig nutzen können, genauso wie ein Nutzer von NC4.
Irgendwann kommt man an den Punkt, wo dieses Ziel nicht mehr mit
der gleichen Optik für völlig veraltete Browser vereinbar ist und
da muß man sich entscheiden, was wichtiger ist.

Ich verzichte nicht auf Funktionalität für Standards

• ich befolge aber Standards, wenn dies bei gleicher
  Funktionalität möglich ist.

Auch wirklich üble Tabellenkonstruktionen können (X)HTML Strict
und CSS valid sein, aber von http://www.w3.org/WAI/ und ähnlichen
Dingen sind sie natürlich dann sehr weit entfernt. Die Verwendung
eines CSS-Layouts ist nicht allein ein technischer Aspekt, viel
ist da auch eine "moralische" Überlegung gegenüber Besuchern,
die mit dem bisherigen (aufgrund der eher schlechten CSS-Unter-
stützung notwendigen) Tabellenlayout Schwierigkeiten haben.
Dazu kommt noch, dass feststehende Navigationsmenüs so wie ich
es auf http://favicon.de praktisch nur mit CSS so realisierbar
sind. In Deinem Fall hätte man wohl auch ein Frameset verwenden
können, wenn die daraus folgenden Nachteile vernachlässig werden.

Deshalb sind meine Dokumente zwar zum großen Teil XHTML
1.1 valide, aber mit vereinzelten target-Attributen.

solange man keine Frames verwendet (ich suche nach wie vor nach
einer sinnvollen Anwendungsmöglichkeit, wo sie auch die bessere
Alternative gegenüber einer Noframes-Lösung darstellen), braucht
man imho kein target-Attribut. _self, _top und _parent sind dann
überflüssig, _blank halte ich idr für nicht sinnvoll und alle
anderen Wert für das target-Attribut sollte man vermeiden.

So, jetzt habe ich wieder ewig lange und viel getippt, muß dann
mal so langsam für diesen Thread reichen, er ist vermutlich eh
schon im Archiv, wenn ich das nächste Mal hier im Forum vorbei-
schauen werde ...

Viele Grüße,
Stefan

[Michael Schröpl]

Hi Stefan,

Selbst wenn der Browser also lediglich prüfen
würde, ob die in seinem Cache vorliegende Datei
aktuell ist, würde das schon mehr kosten, als
den CSS-Code immer wieder komprimiert zu
übertragen!

*ähem* wir sprechen hier nicht von einer einzelnen
Datei, sondern von einer Website. Selbst wenn man
es niedrig ansetzt, wird sich ein Besucher wohl
schon drei Seiten anschauen und da wird dann genau
einmal die CSS-Datei angefordert.

Je nachdem, wie sein Browser konfiguriert ist.

Soll heißen, umso mehr HTML-Dateien vom Besucher
angefordert werden, die diese CSS-Datei
referenzieren, umso größer wird der Vorteil dieser
Lösung.

Das ist richtig.

Dazu kommt noch, dass eventuell nur ein 304 an den
Browser geschickt wird, wenn sie die CSS-Datei nicht
verändert hat.

Und genau dieser angebliche 0-Byte-Request mit HTTP-
Status 304 ist bereits _größer_ als die komprimierte
Auslieferung des CSS-Codes!

Wenn also jemand 10 Seiten abruft, die ein und
diesselbe CSS-Datei einbinden, so werden später
genau 11 Einträge im Logfile stehen.

Oder 20, von denen 11 den Status 200 und 9 den Status
304 haben.
Und es ist _unmöglich_, den Fall der nur 11 Einträge
zu haben, ohne den Browser gezielt von der Prüfung des
Cache-Inhaltes abzuhalten! Dies geht nur
a) durch Browser-Konfiguration "check never" bzw.
   "check once per session" oder
b) durch Browser-Konfiguration "automatic" _und_
   Senden von HTTP-Headern mit Aufbewahrungfrist
   der Datei innerhalb des Cache, was so gut wie
   niemand tut. (Außer gzip_cnc, beispielsweise. ;-)

Es kann natürlich sein, dass in Einzelfällen
Browser so eigenartig konfiguriert sind, dass sie
zehnmal die CSS-Datei anfordern, aber der Normalfall
ist sowas nicht ;-)

Doch, das ist der Normalfall!

Deshalb hat das Self-Portal ja 40% (!) HTTP-304-Requests:
  http://webalizer.teamone.de/selfhtml/usage_200205.htm

Meine eigene Domain, bei der ich aggressiv Expires-
Header sende, hat 'nur' 10-15% 304er-Responses.

Im konkreten Fall ist natürlich noch zu
berücksichtigen, dass Du einzelne CSS-Dateien
unkomprimiert auslieferst, während CSS direkt
in HTML-Dateien mit komprimiert wird.

Daß selbst 304er-Requests größer sind als eine gut
komprimierte eingebundene CSS-Datei, habe ich ja
bereits dargelegt. Bei einer CSS-Datei von 300 Bytes
ist der 304er-Request bereits um Faktor 10 schlechter!

Und erkläre mir bitte, wie Du guten Gewissens CSS-
Dateien separat komprimiert ausliefern willst, solange
die Browser-Implementierungen in diesem Falle derartig
fehlerhaft sind. Die Kröte machst Du damit beispiels-
weise nicht glücklich ...

Allgemein dürfte die Trennung von HTML- und CSS-
Dateien weniger Traffic verursachen.
Ich behaupte nach wie vor das Gegenteil.
Wenn Du diese Behauptung pauschal aufstellst,
dann ist sie falsch.

Nicht falscher als Deine. ;-)

weiter oben beschrieben. Auf
http://de.selfhtml.org/
beispielsweise schauen die meisten Besucher
etliche HTML-Seiten an, da wäre es grober Unfug,
die CSS-Definitionen jedesmal einzeln mit
reinzuschreiben.
Eine externe CSS-Datei, die in fast allen Fällen
genau einmal während eines Besuches angefordert
und geladen wird, ist da sinnvoller.

Ja, aber sie wird eben tatsächlich in sehr vielen
Fällen immer wieder angefordert. Und schon sehr wenige
Fälle würden das Gleichgewicht kippen lassen, denn
eine 300-Bytes-CSS-Datei kostet bei explizitem Zugriff
einfach dreizehnmal so viel wie bei komprimierter Mit-
Auslieferung.
Deine Besucher konfigurieren ihre Browser einfach
nicht optimal - und ob Du Expires-Header sendest, das
ist ja auch erst noch die Frage.

solange man keine Frames verwendet (ich suche nach
wie vor nach einer sinnvollen Anwendungsmöglichkeit,
wo sie auch die bessere Alternative gegenüber einer
Noframes-Lösung darstellen),

Du darfst gerne www.schroepl.net mit seinen über 1000
Dokumenten auf eine frames-lose Variante umschreiben,
die bitte schön ohne SSI funktionieren sollte ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Stefan Einspender]

Hallo Michael,

hast ja schon geantwortet, also dann mal los.

Oder 20, von denen 11 den Status 200 und 9 den Status
304 haben.
Und es ist _unmöglich_, den Fall der nur 11 Einträge
zu haben, ohne den Browser gezielt von der Prüfung des
Cache-Inhaltes abzuhalten! Dies geht nur
a) durch Browser-Konfiguration "check never" bzw.
   "check once per session" oder

also ich bin mir ziemlich sicher, dass Browser standardmäßig so
eingestellt sind, dass sie 11 Abfragen durchführen. Sicher kann
man es umkonfigurieren, dass es 20 werden, aber normal ist das
nicht ;-)
Eventuell haben die Browser da auch bei HTML- und CSS-Dateien
ein anderes Cache-Verhalten, keine Ahnung.

Meine eigene Domain, bei der ich aggressiv Expires-
Header sende, hat 'nur' 10-15% 304er-Responses.

werde ich bei Gelegenheit mal auswerten, sowas mache ich auf
de.selfhtml.org seit einiger Zeit auch und es wäre schon mal
interessant zu sehen, wieviele Zugriffe dadurch weniger sind.
Wobei man das ja nicht ermitteln kann, aber der Anteil der
304'er dürfte schon eine Tendenz zeigen.

Und erkläre mir bitte, wie Du guten Gewissens CSS-
Dateien separat komprimiert ausliefern willst, solange
die Browser-Implementierungen in diesem Falle derartig
fehlerhaft sind. Die Kröte machst Du damit beispiels-
weise nicht glücklich ...

wie gesagt, die würde ich ja dann auch nicht komprimiert aus-
liefern, was natürlich die Wahrscheinlichkeit, dass Deine
Variante die bessere ist, erhöht.

Du darfst gerne www.schroepl.net mit seinen über 1000
Dokumenten auf eine frames-lose Variante umschreiben,
die bitte schön ohne SSI funktionieren sollte ...

danke für die Erlaubnis, ich fange dann sofort damit an ;-)

Im Ernst:
Habe mir jetzt Deine Website nicht genauer angesehen, aber schon
allein die Tatsache, dass Du auch eine framelose (navigations-
technisch allerdings "vereinfachte") Variante anbietest, zeigt
doch, dass die Frames offenbar auch in diesem Fall nicht zwingend
sind. Ob sie sinnvoller sind, müßte man feststellen, vermutlich
wird es jedoch nicht der Fall sein.

So, jetzt habe ich ja noch Deine 1000 Seiten umzuschrieben, bis
dann gleich ;-)

Viele Grüße,
Stefan

[Michael Schröpl]

Hi Stefan,

also ich bin mir ziemlich sicher, dass Browser
standardmäßig so eingestellt sind, dass sie 11
Abfragen durchführen.

wie sollten sie?
Der Browser hat die Aufgabe, sicherzustellen, daß
sein Cache-Inhalt aktuell ist. Das kann er nur,
indem er ein conditional get zum Server sendet -
es sei denn, der Server hat ihm vorher eine Aufbe-
wahrungsdauer geschickt, während welcher der Browser
ihn nicht fragen muß.

Ich kann mir nicht vorstellen, daß "never" oder "once
per session" bei vielen Browsern eingestellt ist.
Der sinnvollste Default wäre "automatic" - aber der
erfordert eben, daß der Server sagt, was der Browser
tun sollte.

Meine eigene Domain, bei der ich aggressiv
Expires-Header sende, hat 'nur' 10-15% 304er-
Responses.
werde ich bei Gelegenheit mal auswerten, sowas mache
ich auf de.selfhtml.org seit einiger Zeit auch und
es wäre schon mal interessant zu sehen, wieviele
Zugriffe dadurch weniger sind.
Wobei man das ja nicht ermitteln kann, aber der
Anteil der 304'er dürfte schon eine Tendenz zeigen.

Eben. Christian sollte das auch mal auf selfhtml.teamone.de machen - dort, wo der größte Teil
des Traffic mit vielen, vielen Referenzen auf die
immer gleichen CSS-Dateien, Markierungs-GIFs etc.
vorkommen. (Wobei die GIFs auch beim Self-Forum besser
nur einmal abgefragt und ansonsten nur noch aus dem
Cache gesaugt würden ... selbst die Forum-Domain hat
25% 304er-Requests.)

Du darfst gerne www.schroepl.net mit seinen über
1000 Dokumenten auf eine frames-lose Variante
umschreiben, die bitte schön ohne SSI
funktionieren sollte ...
danke für die Erlaubnis, ich fange dann sofort damit an ;-)

schon allein die Tatsache, dass Du auch eine
framelose (navigations-technisch allerdings
"vereinfachte") Variante anbietest, zeigt doch,
dass die Frames offenbar auch in diesem Fall nicht
zwingend sind.

Aber sie liefern die Navigation - die frames-lose
Version ist nur mit "vor" und "zurück" navigierbar.

Und bedenke, daß diese Dokumente Druckvorlagen sind
(oder zumindest waren), wobei ich keine Navigations-
Elemente in den vielen einzelnen Dokumenten drin
haben durfte, die ich mangels hinreichenden CSS-
Kenntnissen nicht für die Druck-Version ausblenden
könnte (vor drei Jahren).

Außerdem enthalten viele dieser Dokumente sehr breite
Tabellen - da würde eine Navigation in der Art von
gzip_cnc nicht seitlich daneben passen.
Eine Navigation in Quer-Form wiederum limitiert mich
auf eine nicht bekannte Maximalzahl von Einträgen,
auch noch abhängig von der eingestellten Schriftgröße
im Browser.
Es hat schon seinen Sinn, wieso meine Navigation kom-
plett auf Frames mit GIF-Buttons einer mir pixelgenau
bekannten Breite basiert - bei 800*600 oder mehr weiß
ich wenigstens halbwegs, wie es aussehen wird.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Orlando]

Hi, Michael

bitte anschnallen...

Aktueller Screenshot N4.78:
  <img src="http://www.skop.net/self/gzip_cnc_n4c.gif" border=0 alt="">

Darüber hinaus sind die Menü-Links nicht anklickbar... Der alte Herr reagiert nämlich auf Border-Angaben bei Links ziemlich allergisch. Der Grund liegt in deiner Angabe von

#nav p {border:1px #00f solid;}
 #nav a {border:1px #666 dotted;}

Abhilfe bringt hier eine media-Angabe wie etwa

@media screen {
  #nav p {border:1px #00f solid;}
  #nav a {border:1px #666 dotted;}
 }

Dann klappt's auch wieder mit N4.x. So, ich denke, das war's jetzt ;)

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Stefan Einspender]

Hallo Orlando,

Aktueller Screenshot N4.78:
  <img src="http://www.skop.net/self/gzip_cnc_n4c.gif" border=0 alt="">

ja, also der Michael ist ein ganz schlimmer! ;-)

Hat er doch noch in <?m=80550&t=14094> behauptet:
"Ich habe nichts "verändert". Dieses style-Attribut
stand bereits in der Original-Datei drin."

Also wo ich das letzte Mal vor paar Tagen mit NC4 auf der Seite
war, waren da noch keine Ränder um die Navigationslinks, tztztz ...

Abhilfe bringt hier eine media-Angabe wie etwa

@media screen {
  #nav p {border:1px #00f solid;}
  #nav a {border:1px #666 dotted;}
}

genau, habe ich ja auch schon in <?m=80317&t=14094> vorgeschlagen,
die Rückfrage (heißt das "ja" auf meine obige Frage?) habe ich
leider übersehen, Orlando hat es ja jetzt hier beantwortet.

Also dann, hoffen wir mal, dass Michael nicht wieder still und
leise Änderungen vornimmt, die bei NC4 zu schlimmen Resultaten
führen ;-)

Wie man sieht, ist dazu nahezu jede, scheinbar noch so simple, CSS-
Definition geeignet, NC4 aus der Fassung zu bringen :-(

Viele Grüße,
Stefan

[Orlando]

Hi Stefan,

Aktueller Screenshot N4.78:

<img src="http://www.skop.net/self/gzip_cnc_n4c.gif" border=0 alt="">

ja, also der Michael ist ein ganz schlimmer! ;-)

ja, dabei aber sehr stylish... ;)

Hat er doch noch in ?m=80550&t=14094 behauptet:
"Ich habe nichts "verändert".

Ach ja, war wohl 'getestet' gemeint >;)

Also wo ich das letzte Mal vor paar Tagen mit NC4 auf der Seite
war, waren da noch keine Ränder um die Navigationslinks, tztztz ...

In </?m=80183&t=14094> habe ich ihn sogar gelobt, weil der das Aussehen 'augemotzt' hatte. Damit waren unter anderem die Ränder gemeint. An N4 dachte ich natürlich nicht, der ist mir erst heute eingefallen.

Also dann, hoffen wir mal, dass Michael nicht wieder still und
leise Änderungen vornimmt, die bei NC4 zu schlimmen Resultaten
führen ;-)

Ja, noch ein letzter Tip für den lieben Michael: ändern, testen, testen, testen. Speziell, wenn's um das Relikt geht, denn es ist wirklich unberechenbar.

Wie man sieht, ist dazu nahezu jede, scheinbar noch so simple, CSS-
Definition geeignet, NC4 aus der Fassung zu bringen :-(

Und damit die Bastelei nicht fad wird, hier noch ein 'klein wenig' Lektüre:

http://www.richinstyle.com/bugs/netscape4.html
  http://css.nu/pointers/bugs-nn.html

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Michael Schröpl]

Hi Stefan,

Hat er doch noch in <?m=80550&t=14094> behauptet:
"Ich habe nichts "verändert". Dieses style-Attribut
stand bereits in der Original-Datei drin."

Hatte ich damals auch nicht.

Also wo ich das letzte Mal vor paar Tagen mit NC4 auf der Seite
war, waren da noch keine Ränder um die Navigationslinks, tztztz ...

Wahr. Die Ränder habe ich _jetzt_ nachträglich dazu
gebastelt (_nach_ obigem Posting).

Abhilfe bringt hier eine media-Angabe wie etwa
@media screen {
  #nav p {border:1px #00f solid;}
  #nav a {border:1px #666 dotted;}
}
genau, habe ich ja auch schon in
<?m=80317&t=14094> vorgeschlagen,

und ich gerade eingebaut - hurra, es tut wieder.

Schwarze Felder bei "obskurem" CSS kannte ich von
der Kröte bereits - er versucht beispielsweise,
"inherit" als numerischen Farbton zu parsen, was
natürlich zum Ergebnis "000" führt ... - aber daß
durch den Rand die Links nicht mehr anklickbar sind,
finde ich schon etwas erschütternd.

Also dann, hoffen wir mal, dass Michael nicht wieder
still und leise Änderungen vornimmt,

Glück auf ... ;-)

die bei NC4 zu schlimmen Resultaten führen ;-)

Gibt es auch andere? :-\

Wie man sieht, ist dazu nahezu jede, scheinbar noch
so simple, CSS-Definition geeignet, NC4 aus der
Fassung zu bringen :-(

Eben.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael
(in einer Pause zwischen dem Übersetzen der vielen gzip_cnc-Doku nach Englisch, ächz)

[Michael Schröpl]

Hallo Orlando,

bitte anschnallen...
Aktueller Screenshot N4.78:

habe ich lokal auch schon gesehen.

Noch ist Netscape 4 ja mein Mail-Client - und da mir
Mozilla 1.0 während des Versuchs, seine Mail-Konfigu-
ration entsprechend anzupassen, _zweimal_ abgestürzt
ist (talkback-reports sind unterwegs), scheint das
auch erst mal so zu bleiben. :-(

Abhilfe bringt hier eine media-Angabe wie etwa
@media screen {
  #nav p {border:1px #00f solid;}
  #nav a {border:1px #666 dotted;}
}

Sollte ich von den übrigen Definitionen noch irgendwas
besser nach @screen verschieben?

Dann klappt's auch wieder mit N4.x.

Tut es - vielen Dank.

So, ich denke, das war's jetzt ;)

Bis zum nächsten Abenteuer meinerseits ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael in Krötenland

[Orlando]

Hi Michael,

Sollte ich von den übrigen Definitionen noch irgendwas
besser nach @screen verschieben?

da es mit den derzeitigen Angaben keine Probleme gibt, nein.

Bis zum nächsten Abenteuer meinerseits ...

... das absolut reibungslos verlaufen wird, da sich bestimmt wieder einige Reiseleiter melden ;)

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Christian Kruse]

Moin Michael,

mod_gzip kann nicht anders (noch! ;-), weil es stati-
sche und dynamische Inhalte gleichermaßen komprimiert
ausliefern kann und nicht versucht, zwischen beiden
irgendwie zu unterscheiden.

Das wird sich mit dem naechsten Release aendern ;-)

Ausgehend von dieser Situation haben Christian und ich
ein System diskutiert, entworfen, implementiert, ge-
testet, von Perl nach C portiert und ausführlich doku-
mentiert,

Nun, die Hauptarbeit hast du gemacht. Ich habe nur ab und zu ein
wenig Code-Reviewing und ein paar Verbesserungen gemacht.

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

da habe ich Dich letzthin so genervt, den Code zu veröffentlichen und dann bekomme ich es erst einen Tag später mit ;-)

Aber auf jeden Fall:
Gratulation!

Ausgehend von dieser Situation haben Christian und ich
ein System diskutiert, entworfen, implementiert, ge-
testet, von Perl nach C portiert

Ich habe beim unten angegebenem Link nur eine Version in Perl gefunden?

http://www.schroepl.net/projekte/gzip_cnc/

so short

Christoph Zurnieden

[Christian Kruse]

Hallo Christoph,

Ausgehend von dieser Situation haben Christian und ich
ein System diskutiert, entworfen, implementiert, ge-
testet, von Perl nach C portiert

Ich habe beim unten angegebenem Link nur eine Version in Perl gefunden?

Unter "Versionen" haettest du einen Link auf

http://wwwtech.de/gzip_cncc/gzip_cncc.html

gefunden ;-)

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Ich habe beim unten angegebenem Link nur eine Version in Perl gefunden?

Unter "Versionen" haettest du einen Link auf

http://wwwtech.de/gzip_cncc/gzip_cncc.html

gefunden ;-)

Huppsala!

Tja, mit Brille wär das nicht passiert ;-)

Dankeschön

Na, dann schau ich mal.

Zeile 0: bitte noch ein #include <unistd.h> einbauen (für getpid(), unlink() und close())

Zeile 42 [ sic! ;-) ] : Bitte englische Orthographie beachten, macht einen besseren Eindruck.
Sieht aber auf jeden Fall lustig aus ;-)

(Zeile 44 ff: der alte Macteiler ist IMHO ':', wenn's gebraucht werden sollte)

Zeilen 86, 89 und Funktionen: Bitte alle globalen Variablen vermeiden. Auch hier.Auch die Funktionen selber!

Zeile 102: Der Name 'log(const char *format, ...)' der Funktion beißt sich mit log(double) aus der math.h. Würde ich zu vermeiden suchen.

Zeile 204: mkdir() kann auch in die Hose gehen, fehlt Überprüfung.

Zeile 233: getpid() gibt pid_t zurück, das muß nicht zwingend ein int sein.
Lieber so:
    rd = sprintf(buff, "%d", (int)(getpid()));

Zeile 234: malloc() ohne Überprüfung? Ganz böse Falle, aber wirklich _ganz_ böse!

Zeile 235,236: fehlt beide Male die Überprüfung und weder strcpy() noch strcat() sind eigentlich zu empfehlen. Geht aber hier.

Zeile 253: Überprüfung von fclose() fehlt.

Zeile 271: Memory Leak! gz ist noch nicht freigegeben vor dem return!

Zeile 281: bitte size_t und int nicht mischen. size_t kann durchaus ein long int sein.

(folgt noch einiges Ignorieren der Rückgaben der Funktionen, keine Lust mehr zum Listen ;-)

Zeile 294: siehe 271

(folgt noch einiges Ignorieren der Rückgaben der Funktionen, keine Lust mehr zum Listen ;-)

Zeile 315: siehe 271, 294

Zeile 343: sowas geht nicht gut. Hau lieber noch ein paar Klammern drumherum.

if ((gzip = strstr(gzip, "gzip"))) {

Zeile 348: *gzip != 0 passt nicht. Die Stelle auf die der Pointer zeigt ist Type char, 0 ist Type int.

Zeile 390, 403: getenv("PATH_INFO") kann NULL zurückgeben, das kollidiert dann mit Deiner log() Funktion.

Zeile 443, 450, 458, 525, 532, 540: tptr kann NULL sein, verträgt sich mit strftime() nicht.

Zeile 563: fwrite() will als drittes Argument ein size_t, rd ist aber int.

Zeile 585: malloc() nicht überprüft!

Zeile 597: Typen passen nicht rlen = strlen(CACHE_PATH) rlen ist int, strlen() gibt size_t zurück.

Zeile 599: close() will als erstes Argument ein int, bekommt aber eine FILE*
Beschwert sich übrigens auch der GCC drüber!
Aber hast Du wahrscheinlich nicht verstanden, oder?
Gut, zugegeben ist ein wenig kryptisch die Meldung ;-)

gzip_cncc.c:599: warning: passing arg 1 of `close' makes integer from pointer without a cast

Wolltest Du evt fclose()? Hast zumindest fopen() genommen.
Typo?

Zeile 601: unpassender Vergleich *CACHE_PATH == 0, *CACHE_PATH ist char, 0 ist int.

Zeile 632: may_gzip() ist weder bool noch int.

Zeile 636: malloc() nicht überprüft!

Nach Reparatur von 343 und 599 hat  gcc -Wall -pedantic -ansi  gzip\_cncc.c -lz gar keine Beschwerden mehr.

Nur die malloc() Angelegenheiten sollten unbedingt repariert werden. Den Rest kannst Du auch erstmal lassen.

Ich habe hier zu Hause kein CGI eingerichtet, deshalb kann ich das nicht ausprobieren. Sonst hätte ich Dir einfach einen Patch geschickt.
So faul bin ich ja auch wieder nicht ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Moin Christoph,

na, *das* nenne ich doch mal eine 'konstruktive Kritik' -- danke!

Zeile 0: bitte noch ein #include <unistd.h> einbauen (für getpid(),
unlink() und close())

Hm, bisher dachte ich, das waere in der stdlib.h definiert -- danke fuer den
Hinweis.

(Zeile 44 ff: der alte Macteiler ist IMHO ':', wenn's gebraucht werden
sollte)

Ich habe keinen Mac zum testen. Da muesste sich ein Mac-Freak hinsetzen und
das patchen.

Zeilen 86, 89 und Funktionen: Bitte alle globalen Variablen vermeiden. Auch
hier.Auch die Funktionen selber!

Jaja, ich weiss. Ich hatte eh vor, fuer V. 1.0 das Log-Konzept komplett zu
ueberarbeiten.

Zeile 102: Der Name 'log(const char *format, ...)' der Funktion beißt sich
mit log(double) aus der math.h. Würde ich zu vermeiden suchen.

Danke.

Zeile 204: mkdir() kann auch in die Hose gehen, fehlt Überprüfung.

Stimmt. Daraus wollte ich eh noch ein

if(ret && errno != EEXIST) {
       perror("mkdir");
       return -1;
     }

machen, habe es aber vergessen.

Zeile 234: malloc() ohne Überprüfung? Ganz böse Falle, aber wirklich _ganz_
böse!

Find ich gar nicht. Wann sollte *heutzutage* noch ein malloc() fehlschlagen,
gerade wenn es nur um ein paar Bytes geht?

und weder strcpy() noch strcat() sind eigentlich zu empfehlen.

Warum?

Zeile 253: Überprüfung von fclose() fehlt.

Danke, guter Punkt! :-)

Zeile 271: Memory Leak! gz ist noch nicht freigegeben vor dem return!

Bitte wie? 'gz' sollte doch fclose() freigeben, ich habe den Speicher
schliesslich nicht angefordert. Und ich habe noch keinen Sourcecode gesehen,
wo ein FILE * freigegeben wird.

Zeile 343: sowas geht nicht gut. Hau lieber noch ein paar Klammern drumherum.

if ((gzip = strstr(gzip, "gzip"))) {

Noajoa, es waere gut gegangen. Aber -pedantic will halt noch eine Klammer
haben...

Zeile 348: *gzip != 0 passt nicht. Die Stelle auf die der Pointer zeigt
ist Type char, 0 ist Type int.

Zum Glueck weiss der Compiler das auch und macht daraus einen char :-)

Zeile 390, 403: getenv("PATH_INFO") kann NULL zurückgeben, das kollidiert
dann mit Deiner log() Funktion.

Danke, guter Hinweis.

Zeile 443, 450, 458, 525, 532, 540: tptr kann NULL sein, verträgt sich mit
strftime() nicht.

Hm. Warum sollte tptr null sein koennen? Bzw. in welchem Fall? Aber ich habe
es beruecksichtigt jetzt, danke.

Zeile 599: close() will als erstes Argument ein int, bekommt aber eine FILE*
Beschwert sich übrigens auch der GCC drüber!
Aber hast Du wahrscheinlich nicht verstanden, oder?

Doch, natuerlich ;-) Ich habe nur nicht mit -Wall compiliert, zum Schluss. Das
mit der 'filename.conf' war mehr oder weniger ein Release-Quickhack, damit
ich bei den Binaries nicht den Cache-Pfad fest einkompilieren muss.

Gut, zugegeben ist ein wenig kryptisch die Meldung ;-)

Ja, aber nach ein paar Programmen lernt man die Meldung einschaetzen ;-)

Wolltest Du evt fclose()? Hast zumindest fopen() genommen.

Ja, wollte ich.

Typo?

Genau :-)

Zeile 632: may_gzip() ist weder bool noch int.

Doch, may_gzip() ist

int may_gzip(void)

Nach Reparatur von 343 und 599 hat  gcc -Wall -pedantic -ansi gzip\_cncc.c -lz gar keine Beschwerden mehr.

Dito.
Ich kannte -pedantic und -ansi vorher gar nicht. -Wall sind anscheinend doch
nicht alle Warnungen?

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

na, *das* nenne ich doch mal eine 'konstruktive Kritik' -- danke!

Jaja, da bemüht man sich und bekommt es dann noch um die Ohren gehauen.
Das Schlimmste ist ja: sogar noch zu Recht! ;-)

Zeile 0: bitte noch ein #include <unistd.h> einbauen (für getpid(),
unlink() und close())

Hm, bisher dachte ich, das waere in der stdlib.h definiert -- danke fuer den
Hinweis.

Weder getpid(), close() noch unlink() sind ANSI C 99.
unistd.h übrigens auch nicht ;-)
Macht auch normalerweise der Compiler selber, gibt halt nur bei 'gcc -pedantic -ansi -Wall' eine Warnung aus.
Kann auch sein, daß meine Libc zu alt ist (GLibc 2.0.irgendwas)

BTW: ist das evt keine gute Idee auf allzuviele nicht ANSI C Funktionen zurückzugreifen?

Achso: man müßte mal schauen, ob da Haken drin sind, die bei 64 Bit Architekturen hängen könnten. Sollte zwar nichts drin sein, aber ...

(Zeile 44 ff: der alte Macteiler ist IMHO ':', wenn's gebraucht werden
sollte)

Ich habe keinen Mac zum testen. Da muesste sich ein Mac-Freak hinsetzen und
das patchen.

Würde auch eh nur für die alten Mac OS < 10 gelten.
Und da einen Server drauf? Na, ich weiß ja nicht ;-)

Zeile 234: malloc() ohne Überprüfung? Ganz böse Falle, aber wirklich _ganz_
böse!

Find ich gar nicht. Wann sollte *heutzutage* noch ein malloc() fehlschlagen,
gerade wenn es nur um ein paar Bytes geht?

Da Du nicht weißt, wie malloc() auf der jeweiligen Architektur funktioniert, gibt es einige Gründe.

Kannst Dein malloc() an den meisten Stellen eh ganz weglassen.

(Hatte ich nicht von Dir neulich mal einen Preis bekommen für die "most useless pipe", oder war das der Michael? ;-)

und weder strcpy() noch strcat() sind eigentlich zu empfehlen.

Warum?

strcpy() weil in Deinem Fall tempfile = cfile (+ der danach notwendigen Änderungen) besser gewesen wäre, hätte auch die Speicherallokation gespart. (Nur die Adresse wird kopiert)

strcpy() kann in die Hose gehen, wenn Argument 1 kein regulärer C String ist (kein \0 am Ende).

Wenn Du nicht auf strcpy() verszichten willst, dann nimm wenigstens strncpy()

strcat() läßt sich dann auch auf fast gleiche Weise ersetzen und hat fast die gleichen Probleme mit fast der gleichen Lösung.

Vielleicht ist es aber auch nur Geschmackssache ;-)

Zeile 253: Überprüfung von fclose() fehlt.

Danke, guter Punkt! :-)

Jaja, ich und mein Lint ;-)

(Bin ich denn eigentlich nur blind? Ich bin da auch noch fast alles im Code nachgegangen. Nunja, "fast" alles trifft es da gut ;-)

Zeile 271: Memory Leak! gz ist noch nicht freigegeben vor dem return!

Bitte wie? 'gz' sollte doch fclose() freigeben, ich habe den Speicher
schliesslich nicht angefordert.

Ja und?

Und ich habe noch keinen Sourcecode gesehen,
wo ein FILE * freigegeben wird.

Stimmt, da habe ich mich wohl zu sehr auf mein Lint verlassen.
Scheint ein Bug (im Lint) zu sein, muß ich wohl nochmal bei.
'tschuldigung.

(2. Mal schon! Peinlich, peinlich!)

Zeile 343: sowas geht nicht gut. Hau lieber noch ein paar Klammern drumherum.

if ((gzip = strstr(gzip, "gzip"))) {

Noajoa, es waere gut gegangen. Aber -pedantic will halt noch eine Klammer
haben...

;-)
Aber ist immer besser. Wer weiß, welcher Compiler da dran geht. Kann ja nicht immer GCC sein ;-)

Zeile 348: *gzip != 0 passt nicht. Die Stelle auf die der Pointer zeigt
ist Type char, 0 ist Type int.

Zum Glueck weiss der Compiler das auch und macht daraus einen char :-)

Was suchst Du da eigentlich? \0, also Ende vom String?
NULL, also Ende vom Speicher?
'0', die Zahl Null als Buchstabe?
Dann schreib das doch einfach ;-)

Zeile 443, 450, 458, 525, 532, 540: tptr kann NULL sein, verträgt sich mit
strftime() nicht.

Hm. Warum sollte tptr null sein koennen? Bzw. in welchem Fall? Aber ich habe
es beruecksichtigt jetzt, danke.

time() kann versagen, localtime() kann versagen.
Irgendwie sieht das sowieso komisch aus. Ich mache bei time() immer:

time_t t;
time(&t);

time(NULL) habe ich noch nie gesehen ;-)

BTW: NULL kann auch als (void)(0) definiert sein. (Ich z.B. mache das immer) Das passt dann nicht in time() rein. Gibt zumindest 'ne Warnung.

Zeile 599: close() will als erstes Argument ein int, bekommt aber eine FILE*
Beschwert sich übrigens auch der GCC drüber!
Aber hast Du wahrscheinlich nicht verstanden, oder?

Doch, natuerlich ;-) Ich habe nur nicht mit -Wall compiliert,

Tststs ;-)))

BTW: welche Optimierung verträgt er eigentlich?
Schonmal ausprobiert?

zum Schluss. Das
mit der 'filename.conf' war mehr oder weniger ein Release-Quickhack, damit
ich bei den Binaries nicht den Cache-Pfad fest einkompilieren muss.

Könnte ja jetzt sagen: "So sieht's auch aus!", aber wer bin ich denn ;-)

Dadurch hast Du aber auch noch eine globale Variable, die Du ganz schlecht wegbekommst. (Die andere (LgFile) ist einfach)

Zeile 632: may_gzip() ist weder bool noch int.

Doch, may_gzip() ist

int may_gzip(void)

Ja, selbst zu blöd zum abschreiben bin ich:

gzip_cncc.c:632:6: Test expression for if not boolean, type int: may_gzip()

steht da ja auch! Und ich wollte gerade wieder meinem Lint die Schuld in die Schuhe schieben ;-)

(Das void steht bei mir aber nicht! ;-)

Nach Reparatur von 343 und 599 hat  gcc -Wall -pedantic -ansi gzip\_cncc.c -lz gar keine Beschwerden mehr.

Dito.
Ich kannte -pedantic und -ansi vorher gar nicht. -Wall sind anscheinend doch
nicht alle Warnungen?

Nein, noch lange nicht ;-)

Wenn Du das Revidierte oben hast, sag doch mal eben Bescheid.
Dann geh ich da mal in Ruhe durch.
Und vor allem zu Fuß!
Scheiß Lint!
*grummel* ;-)

BTW: Bennen Doch bitte Dein Makro EXPIRE um, alle Makros mit dem Anfagsbuchstaben "E" sind reserviert. Mach einfach CNC_EXPIRE o.ä.

so short

Christoph Zurnieden

PS: sehe ich gerade. Schau doch mal ganz oben in die Zeile, wo Dein Name steht.
Ja, genau ;-)
CZ

PPS:
Warum meinst Du eigentlich, das eine PID bis zu 1024 Stellen haben kann?
Nur so als Frage ;-)
CZ

[Christian Kruse]

Hoi,

na, *das* nenne ich doch mal eine 'konstruktive Kritik' -- danke!

Jaja, da bemüht man sich und bekommt es dann noch um die Ohren gehauen.
Das Schlimmste ist ja: sogar noch zu Recht! ;-)

Hae?

Weder getpid(), close() noch unlink() sind ANSI C 99.

Von close() wusste ich das ja. Aber bei getpid() und unlink() haett ich das
jetzt nicht gedacht. Auf welche Ersatz-Funktion sollte man denn zugreifen,
anstelle von unlink()?

unistd.h übrigens auch nicht ;-)

Ach ne ;-)

BTW: ist das evt keine gute Idee auf allzuviele nicht ANSI C Funktionen
zurückzugreifen?

Ja. Im Moment sind es zwei. Wenn du mir sagst, wie ich das noch weiter
reduzieren kann... ich muss halt irgendwie ein eindeutiges Merkmal erhalten
(deshalb getpid()) und irgenwie die Datei wieder entfernen.

Zeile 234: malloc() ohne Überprüfung? Ganz böse Falle, aber wirklich
_ganz_ böse!

Find ich gar nicht. Wann sollte *heutzutage* noch ein malloc()
fehlschlagen, gerade wenn es nur um ein paar Bytes geht?

Da Du nicht weißt, wie malloc() auf der jeweiligen Architektur funktioniert,
gibt es einige Gründe.

Nenn mir mal einen, damit mein Verstaendnis dafuer waechst ;-)

Kannst Dein malloc() an den meisten Stellen eh ganz weglassen.

Sicher, aber dann muesste ich mit festen Groessen arbeiten (Arrays), und das
moechte ich moeglichst vermeiden. So kann ich die Groesse ziemlich genau
bestimmen.

(Hatte ich nicht von Dir neulich mal einen Preis bekommen für die "most
useless pipe", oder war das der Michael? ;-)

Nein, ich hatte gesagt, das sei 'useless use of a pipe' -- aber meinetwegen
koennen wir gerne einen Preis draus machen *g*

und weder strcpy() noch strcat() sind eigentlich zu empfehlen.

Warum?

strcpy() weil in Deinem Fall tempfile = cfile (+ der danach notwendigen
Änderungen) besser gewesen wäre, hätte auch die Speicherallokation gespart.
(Nur die Adresse wird kopiert)

Aber dann haette ich die Zahl wieder hinten dran gehabt, und auch haette ich
das Problem, dass evntl. die Laenge zu gross wird.

strcpy() kann in die Hose gehen, wenn Argument 1 kein regulärer C String
ist (kein \0 am Ende).

Ja, das weiss ich. Damit kann ich umgehen, es ist ja in dem Fall
sichergestellt, dass die Strings 0-terminiert sind.

[... strncpy(), strncat() ...]

Das setze ich auch ein. Wenn ich mich nicht drauf verlassen kann. Aber hier
sehe ich den Sinn nicht.

(Bin ich denn eigentlich nur blind? Ich bin da auch noch fast alles im Code
nachgegangen. Nunja, "fast" alles trifft es da gut ;-)

Hae?

Zeile 271: Memory Leak! gz ist noch nicht freigegeben vor dem return!

Bitte wie? 'gz' sollte doch fclose() freigeben, ich habe den Speicher
schliesslich nicht angefordert.

Ja und?

Wenn ich den Speicher nicht explizit angefordert habe, dann muss IMHO bei der
Beschreibung der Funktion ganz fett und in Grossbuchstaben, unterstrichen und
blinkend stehen 'You have to free() the memory!' ;-)
Das halte ich fuer ganz, ganz schlechten Code.

;-)
Aber ist immer besser. Wer weiß, welcher Compiler da dran geht. Kann ja
nicht immer GCC sein ;-)

Jaja, ich weiss ja *noergel* ;-)

Zeile 348: *gzip != 0 passt nicht. Die Stelle auf die der Pointer zeigt
ist Type char, 0 ist Type int.

Zum Glueck weiss der Compiler das auch und macht daraus einen char :-)

Was suchst Du da eigentlich? \0, also Ende vom String?

Ja.

NULL, also Ende vom Speicher?

Hae? Seit wann sind Felder NULL-Terminiert, wenn man das nicht per Hand macht?

'0', die Zahl Null als Buchstabe?

Noe.

Dann schreib das doch einfach ;-)

'\0' sind drei Buchstaben mehr *jammer* ;-)

time() kann versagen, localtime() kann versagen.

Warum?

Irgendwie sieht das sowieso komisch aus. Ich mache bei time() immer:

time_t t;
time(&t);

time(NULL) habe ich noch nie gesehen ;-)

Lies mal time(3) ;-)
Da steht:

SYNOPSIS
     #include <time.h>

time_t
     time(time_t *tloc);
[...]
     The time() function returns the value of time in seconds since 0 hours, 0
     minutes, 0 seconds, January 1, 1970, Coordinated Universal Time.

A copy of the time value may be saved to the area indicated by the
     pointer tloc.  If tloc is a NULL pointer, no value is stored.

Du siehst: 'a copy of the time value'.

BTW: NULL kann auch als (void)(0) definiert sein. (Ich z.B. mache das immer)
Das passt dann nicht in time() rein. Gibt zumindest 'ne Warnung.

Warum machst du sowas auch? ;-)

BTW: welche Optimierung verträgt er eigentlich?
Schonmal ausprobiert?

Nein.
Diese Optimierungen vom GCC sind mir suspekt...

Ich hab da ganz schlimme Dinge gehoert, z. B. sowas wie Aufrollen von
Schleifen *schuettel*

zum Schluss. Das
mit der 'filename.conf' war mehr oder weniger ein Release-Quickhack, damit
ich bei den Binaries nicht den Cache-Pfad fest einkompilieren muss.

Könnte ja jetzt sagen: "So sieht's auch aus!", aber wer bin ich denn ;-)

Wieso?
Zugegeben, es mag vielleicht keine Loesung im C-Style sein. Aber sie ist doch
einfach und elegant?

Dadurch hast Du aber auch noch eine globale Variable, die Du ganz schlecht
wegbekommst. (Die andere (LgFile) ist einfach)

Och, wir werden sehen. Frueher war das halt ein '#define'.

gzip_cncc.c:632:6: Test expression for if not boolean, type int: may_gzip()

steht da ja auch! Und ich wollte gerade wieder meinem Lint die Schuld in die
Schuhe schieben ;-)

Hehe ;-)
Da es in C keine Booleans gibt, halte ich die Fehlermeldung fuer falsch.

(Das void steht bei mir aber nicht! ;-)

Dann guck dir mal den aktuellen Sourcecode an ;-)

Nein, noch lange nicht ;-)

Gibt es einen Switch, der alle Warnungen ausgibt?

Wenn Du das Revidierte oben hast, sag doch mal eben Bescheid.

Bescheid.

Scheiß Lint!
*grummel* ;-)

Hoehoe ;-))

BTW: Bennen Doch bitte Dein Makro EXPIRE um, alle Makros mit dem
Anfagsbuchstaben "E" sind reserviert. Mach einfach CNC_EXPIRE o.ä.

[x] Done. Aber noch nicht hochgeladen.

PS: sehe ich gerade. Schau doch mal ganz oben in die Zeile, wo Dein Name
steht. Ja, genau ;-)

Na, da siehst du mal: ich bin selbst zu bloed, meinen Namen zu schreiben ;-))

Warum meinst Du eigentlich, das eine PID bis zu 1024 Stellen haben kann?
Nur so als Frage ;-)

Wer sagt, dass ich das meine? ;-)
Ich verwende 'buff' noch etwas spaeter, als fread()-Buffer.

Gruesse,
 CK

[Michael Schröpl]

Hallo Christian,

'\0' sind drei Buchstaben mehr *jammer* ;-)

ich konnte beim besten Willen keinen Buchstaben in diesem String finden ...

Diese Optimierungen vom GCC sind mir suspekt...
Ich hab da ganz schlimme Dinge gehoert, z. B. sowas wie Aufrollen von
Schleifen *schuettel*

Ist doch schön! Der klassische trade-off zwischen Rechenkraft und Speicher.
Was ist da schlimm dran? Womöglich paßt der Code danach immer noch in
dieselbe Anzahl Hauptspeicherseiten ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.ico" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Na, auch "Nachtschicht"? ;-)

'\0' sind drei Buchstaben mehr *jammer* ;-)

ich konnte beim besten Willen keinen Buchstaben in diesem String finden ...

C-Programmierer: char == Buchstabe.
Tja, was soll man da machen? ;-)

Diese Optimierungen vom GCC sind mir suspekt...
Ich hab da ganz schlimme Dinge gehoert, z. B. sowas wie Aufrollen von
Schleifen *schuettel*

Ist doch schön! Der klassische trade-off zwischen Rechenkraft und Speicher.
Was ist da schlimm dran?

Ältere GCCs hatten da so ihre Schwierigkeiten ;-)

Womöglich paßt der Code danach immer noch in
dieselbe Anzahl Hauptspeicherseiten ...

Ja, hörmal, soooo schlecht ist der GCC auch wieder nicht! ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Christoph

Na, auch "Nachtschicht"? ;-)

Urlaub kennt keine "Schichten".

'\0' sind drei Buchstaben mehr *jammer* ;-)
ich konnte beim besten Willen keinen Buchstaben in diesem String finden ...
C-Programmierer: char == Buchstabe.
Tja, was soll man da machen? ;-)

Informatiker: Buchstabe =~ /^[1]$/;

Womöglich paßt der Code danach immer noch in
dieselbe Anzahl Hauptspeicherseiten ...
Ja, hörmal, soooo schlecht ist der GCC auch wieder
nicht! ;-)

Er könnte ja einfach Pech haben. Durch das Aufrollen
von Schleifen wird der Code nun mal länger ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.ico" border=0 alt=""> Michael

---

1. A-Za-z ↩︎

[Christoph Zurnieden]

Hallo,

Na, auch "Nachtschicht"? ;-)

Urlaub kennt keine "Schichten".

Deshalb hatte ich meinen ja auch in Anführungszeichen gesetzt.
Aus irgendwelchen Gründen verschiebt sich mein Tagesablauf nach ungefähr 2 Wochen um ziemlich genau 12 Stunden ;-)

'\0' sind drei Buchstaben mehr *jammer* ;-)
ich konnte beim besten Willen keinen Buchstaben in diesem String finden ...
C-Programmierer: char == Buchstabe.
Tja, was soll man da machen? ;-)

Informatiker: Buchstabe =~ /^[1]$/;

Und was ist mit ÄÖÜäöüß alleine im deutschem Alphabet?
Ha?
;-)

Womöglich paßt der Code danach immer noch in
dieselbe Anzahl Hauptspeicherseiten ...
Ja, hörmal, soooo schlecht ist der GCC auch wieder
nicht! ;-)

Er könnte ja einfach Pech haben. Durch das Aufrollen
von Schleifen wird der Code nun mal länger ...

Ja, aber der GCC ist mittlerweile darin sehr geschickt geworden. Es mag bessere Optimierer geben (vor allem die von Intel für ihre eigenen Produkte) liegt aber immer noch sehr deutlich im oberem Viertel.

so short

Christoph Zurnieden

---

1. A-Za-z ↩︎

[Christian Kruse]

Hallo Michael,

'\0' sind drei Buchstaben mehr *jammer* ;-)

ich konnte beim besten Willen keinen Buchstaben in diesem String finden ...

Das ist kein String! Zumindest nicht in den Augen von C ;-)
Naja, leichte Begriffs-Verwirrung. Solange es in einen char (Uebersetzung:
Buchstabe) passt, ists ein Buchstabe fuer mich ;-)

Ist doch schön! Der klassische trade-off zwischen Rechenkraft und Speicher.
Was ist da schlimm dran? Womöglich paßt der Code danach immer noch in
dieselbe Anzahl Hauptspeicherseiten ...

Sobald eine Maschine in meinem Code rumwurschtelt, werde ich ganz, ganz
misstrauisch.

Gruesse,
 CK

[Michael Schröpl]

Hallo Christian,

Sobald eine Maschine in meinem Code rumwurschtelt,
werde ich ganz, ganz misstrauisch.

dann mußt Du aber alles in Maschinensprache schreiben.

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Sagte der mir doch:

Überprüfen Sie bitte Ihre Mitteilung! Sie ist zu lang (maximal 12288 Zeichen).

Ja sowas!

Waren 12325 ohne diese Zeilen.

Is abba kleinlich! ;-)

Weder getpid(), close() noch unlink() sind ANSI C 99.

Von close() wusste ich das ja. Aber bei getpid() und unlink() haett ich das jetzt nicht gedacht. Auf welche Ersatz-Funktion sollte man denn zugreifen, anstelle von unlink()?

Also, ANSI C bietet an:

7.19.4.1 The remove function Synopsis 1 #include <stdio.h> int remove(const char *filename);

Kannst auch unlink() nehemn, mußt aber davon ausgehen, das das nicht unbedingt portabel ist.

unistd.h übrigens auch nicht ;-)

Ach ne ;-)

BTW: ist das evt keine gute Idee auf allzuviele nicht ANSI C Funktionen zurückzugreifen?

Ja. Im Moment sind es zwei. Wenn du mir sagst, wie ich das noch weiter reduzieren kann... ich muss halt irgendwie ein eindeutiges Merkmal erhalten (deshalb getpid()) und irgenwie die Datei wieder entfernen.

Ist ja nur noch getpid()

Ein eindeutiges Merkmal gibt es z.B. mit tmpnam() bzw tmpfile()

Zeile 234: malloc() ohne Überprüfung? Ganz böse Falle, aber wirklich ganz böse!

Find ich gar nicht. Wann sollte heutzutage noch ein malloc() fehlschlagen, gerade wenn es nur um ein paar Bytes geht?

Da Du nicht weißt, wie malloc() auf der jeweiligen Architektur funktioniert, gibt es einige Gründe.

Nenn mir mal einen, damit mein Verstaendnis dafuer waechst ;-)

Du kannst Dich nicht darauf verlassen, daß auch nur ein Byte frei ist (oder besser: alle verlangten Bytes frei sind) und alloziert werden kann. Du kannst Dich nicht darauf verlassen, daß die Speicherverwaltung sauber ist. Der verlangte physische Speicherbereich kann kaputt sein, der Kernel verträgt es, gibt halt nur einen Fehler zurück und merkt sich die kaputte Stelle. (Ganz schön Science Fiction, zugegeben, aber theoretisch machbar ;-) Die malloc() Implementation ist, mit Verlaub, für'n Arsch. Und noch einige Kleinigkeiten die einem besonders unter den verschiedenen MS OSen recht viel Freude bereiten.

Drum prüf die Speicherallozierung auf Erfolg. Kost' nicht viel und beruhigt ungemein ;-)

Kannst Dein malloc() an den meisten Stellen eh ganz weglassen.

Sicher, aber dann muesste ich mit festen Groessen arbeiten (Arrays), und das moechte ich moeglichst vermeiden. So kann ich die Groesse ziemlich genau bestimmen.

Nein, warum? Pointer reichen. Damit kann auch keine Ärger mit der Größe auftauchen.

(Hatte ich nicht von Dir neulich mal einen Preis bekommen für die "most useless pipe", oder war das der Michael? ;-)

Nein, ich hatte gesagt, das sei 'useless use of a pipe'

Achja, der war das ;-)

-- aber meinetwegen koennen wir gerne einen Preis draus machen g

Mmh... ich hätte gerne , ... äääääh ... die Waschmaschine. ;-)

und weder strcpy() noch strcat() sind eigentlich zu empfehlen.

Warum?

strcpy() weil in Deinem Fall tempfile = cfile (+ der danach notwendigen Änderungen) besser gewesen wäre, hätte auch die Speicherallokation gespart. (Nur die Adresse wird kopiert)

Aber dann haette ich die Zahl wieder hinten dran gehabt, und auch haette ich das Problem, dass evntl. die Laenge zu gross wird.

Wieso kann die Länge zu groß werden? Sind doch nur Zeiger. Im Normalfall decken die die ersten 4GB auf jeden Fall ab. Sind sogar individuell, da sparst Du Dir noch das getpid().

strcpy() kann in die Hose gehen, wenn Argument 1 kein regulärer C String ist (kein \0 am Ende).

Ja, das weiss ich. Damit kann ich umgehen, es ist ja in dem Fall sichergestellt, dass die Strings 0-terminiert sind.

Wollte nur aufzählen, Du hattest schließlich gefragt ;-) Aber wie auch schon gesagt: ist wohl doch eher Geschmacksfrage.

[... strncpy(), strncat() ...]

Das setze ich auch ein. Wenn ich mich nicht drauf verlassen kann. Aber hier sehe ich den Sinn nicht.

Sind ein wenig schneller, da sie nicht extra zählen müssen.

Zeile 271: Memory Leak! gz ist noch nicht freigegeben vor dem return!

Bitte wie? 'gz' sollte doch fclose() freigeben, ich habe den Speicher schliesslich nicht angefordert.

Ja und?

Wenn ich den Speicher nicht explizit angefordert habe, dann muss IMHO bei der Beschreibung der Funktion ganz fett und in Grossbuchstaben, unterstrichen und blinkend stehen 'You have to free() the memory!' ;-) Das halte ich fuer ganz, ganz schlechten Code.

"Never trust a programmer!" ;-)

BTW: kam der nicht aus dieser einen Library, wo gerade eben erst ein ganz fieser Buffer Overflow entdeckt wurde? >;->

;-) Aber ist immer besser. Wer weiß, welcher Compiler da dran geht. Kann ja nicht immer GCC sein ;-)

Jaja, ich weiss ja noergel ;-)

"Hömma, das ist ANSI C!" "Hömma, das ist Visual Crap!"

;->

Zeile 348: *gzip != 0 passt nicht. Die Stelle auf die der Pointer zeigt ist Type char, 0 ist Type int.

Zum Glueck weiss der Compiler das auch und macht daraus einen char :-)

Was suchst Du da eigentlich? \0, also Ende vom String?

Ja.

Aha, dacht ich mir doch ;-)

NULL, also Ende vom Speicher?

Hae? Seit wann sind Felder NULL-Terminiert, wenn man das nicht per Hand macht?

Nein, komische Existenzprüfung.

Wenn ich mal in Fahrt bin, dann zähle ich auch alles auf ;-)

Dann schreib das doch einfach ;-)

'\0' sind drei Buchstaben mehr jammer ;-)

Und ich dachte, ich wäre faul ;-)

time() kann versagen, localtime() kann versagen.

Warum?

Frag die libc Programmierer. Alles schon erlebt.

Irgendwie sieht das sowieso komisch aus. Ich mache bei time() immer:

time_t t; time(&t);

time(NULL) habe ich noch nie gesehen ;-)

Lies mal time(3) ;-) Da steht:

SYNOPSIS      #include <time.h>

time_t      time(time_t *tloc); [...]      The time() function returns the value of time in seconds since 0 hours, 0      minutes, 0 seconds, January 1, 1970, Coordinated Universal Time.

A copy of the time value may be saved to the area indicated by the      pointer tloc.  If tloc is a NULL pointer, no value is stored.

Du siehst: 'a copy of the time value'.

Beispiel aus der C FAQ:

#include <stdio.h> #include <time.h>

int main(void){ time_t now; time(&now); printf("It's %.24s.\n", ctime(&now)); return 0;}

Und nicht anders kenn ich das. Was sagt denn die info libc?

time_t curtime; struct tm *loctime;

/* Get the current time. */ curtime = time (NULL);

/* Convert it to local time representation. */ loctime = localtime (&curtime);

Aha, die machen dsa so, wie Du.

Aber hast schon recht, ist wohl Geschmacksache.

BTW: NULL kann auch als (void)(0) definiert sein. (Ich z.B. mache das immer)

(Heißt natürlich (void *)(0), sorry ;-)

Das passt dann nicht in time() rein. Gibt zumindest 'ne Warnung.

Warum machst du sowas auch? ;-)

Um eine definiertes NULL Macro zu haben. Man weiß ja nie, was einem in den verschiedensten Libcs so begegnet.

ANSI C sagt ja nur:

(stddef.h) NULL which expands to an implementation-defined null pointer constant

In stddef.h steht dann auf meiner Maschine:

#define NULL ((void *)0)

Wie heißt es so schön? "Your mileage may vary" ;-)

(Eigentlich darf time() da keine Probleme machen. Ist meine Libc wirklich so kaputt?)

BTW: welche Optimierung verträgt er eigentlich? Schonmal ausprobiert?

Nein. Diese Optimierungen vom GCC sind mir suspekt...

Och nö, geht mittlerweile. Arbeitet sauber. Wenn der Code auch sauber ist! ,-)

Ich hab da ganz schlimme Dinge gehoert, z. B. sowas wie Aufrollen von Schleifen schuettel

man gcc

Optimization Options -fcaller-saves -fcse-follow-jumps -fcse-skip-blocks -fdelayed-branch -felide-constructors -fexpensive-optimizations -ffast-math -ffloat-store -fforce-addr -fforce-mem -finline-functions -fkeep-inline-functions -fmemoize-lookups -fno-default-inline -fno-defer-pop -fno-function-cse -fno-inline -fno-peephole -fomit-frame-pointer -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fstrength-reduce -fthread-jumps -funroll-all-loops -funroll-loops -O -O2 -O3

Such Dir was aus, sind alle dort beschrieben ;-)

zum Schluss. Das mit der 'filename.conf' war mehr oder weniger ein Release-Quickhack, damit ich bei den Binaries nicht den Cache-Pfad fest einkompilieren muss.

Könnte ja jetzt sagen: "So sieht's auch aus!", aber wer bin ich denn ;-)

Wieso? Zugegeben, es mag vielleicht keine Loesung im C-Style sein. Aber sie ist doch einfach und elegant?

Mpfffff...

Öh ...

Klarer Fall von Perl2C ;-)

Dadurch hast Du aber auch noch eine globale Variable, die Du ganz schlecht wegbekommst. (Die andere (LgFile) ist einfach)

Och, wir werden sehen. Frueher war das halt ein '#define'.

Reicht das denn nicht "at compile time"? Mich ärgern hardcompiled paths ja auch unsäglich, aber hier?

gzip_cncc.c:632:6: Test expression for if not boolean, type int: may_gzip()

steht da ja auch! Und ich wollte gerade wieder meinem Lint die Schuld in die Schuhe schieben ;-)

Hehe ;-) Da es in C keine Booleans gibt, halte ich die Fehlermeldung fuer falsch.

Nein, ausnahmsweise richtig ;-)

C99:

7.16 Boolean type and values <stdbool.h> 1 The header <stdbool.h> defines four macros. 2 The macro bool expands to _Bool. 3 The remaining three macros are suitable for use in #if preprocessing directives. They are true which expands to the integer constant 1, false which expands to the integer constant 0, and __bool_true_false_are_defined which expands to the decimal constant 1.

Kann aber erst der GCC 3.x

(Das void steht bei mir aber nicht! ;-)

Dann guck dir mal den aktuellen Sourcecode an ;-)

Ja, bin ich ja schon bei ;-)

Nein, noch lange nicht ;-)

Gibt es einen Switch, der alle Warnungen ausgibt?

Nein, leider nicht. Mußt Du zusammenbauen, oder einen C Lint benutzen, z.B. splint http://www.splint.org mit der Option -strict.

Aber tu Dir das bloß nicht an! ;-)

Warum meinst Du eigentlich, das eine PID bis zu 1024 Stellen haben kann? Nur so als Frage ;-)

Wer sagt, dass ich das meine? ;-) Ich verwende 'buff' noch etwas spaeter, als fread()-Buffer.

Wie ich schon weiter oben erwähnte:

Jaja, typisch perl2C ;-)

BTW: stdio.h

• Macro: int BUFSIZ

The value of this macro is an integer constant expression that is good to use for the SIZE argument to setvbuf'.  This value is guaranteed to be at least 256'.

The value of BUFSIZ' is chosen on each system so as to make stream I/O efficient.  So it is a good idea to use BUFSIZ' as the size for the buffer when you call `setvbuf'. [...]

Bin jetzt mal kurz über den Code gehüpft. Viel geändert hat sich nicht. Werde mal per PM selber einen Vorschlag unterbreiten. Wird hier im Forum dann doch zuviel. (Ja, wenn man einmal mal einen auf den Sack wg OT bekommen hat .. ,-)

so short

Christoph Zurnieden

[Christian Kruse]

Moin,

Überprüfen Sie bitte Ihre Mitteilung! Sie ist zu lang (maximal 12288 Zeichen).

Ja sowas!

Hoehoe ;-) Fass dich halt kuerzer *g*

Also, ANSI C bietet an:

7.19.4.1 The remove function
Synopsis
1 #include <stdio.h>
int remove(const char *filename);

Ah. Sehr cool, danke.

Ist ja nur noch getpid()

Ein eindeutiges Merkmal gibt es z.B. mit tmpnam() bzw tmpfile()

Oh, kannte ich auch noch nicht. Mal sehen, was die man-Page sagt:

BUGS
     These interfaces are provided for System V and ANSI compatibility only.
     The mkstemp(3) interface is strongly preferred.

There are four important problems with these interfaces (as well as with
     the historic mktemp(3) interface).  First, there is an obvious race
     between file name selection and file creation and deletion.  Second, most
     historic implementations provide only a limited number of possible tempo-
     rary file names (usually 26) before file names will start being recycled.
     Third, the System V implementations of these functions (and of mktemp(3))
     use the access(2) function to determine whether or not the temporary file
     may be created.  This has obvious ramifications for setuid or setgid pro-
     grams, complicating the portable use of these interfaces in such pro-
     grams.  Finally, there is no specification of the permissions with which
     the temporary files are created. [...]

Vor allen Dingen der erste Punkt macht mich stutzig; eine race condition kann
ich echt nicht brauchen. Weisst du naeheres darueber?

Kannst Dein malloc() an den meisten Stellen eh ganz weglassen.

Sicher, aber dann muesste ich mit festen Groessen arbeiten (Arrays), und
das moechte ich moeglichst vermeiden. So kann ich die Groesse ziemlich
genau bestimmen.

Nein, warum? Pointer reichen. Damit kann auch keine Ärger mit der Größe
auftauchen.

Bitte was?
Entschuldige, aber wie soll ich hier sonst einen String zusammensetzen? ;-)

und weder strcpy() noch strcat() sind eigentlich zu empfehlen.

Warum?

strcpy() weil in Deinem Fall tempfile = cfile (+ der danach notwendigen
Änderungen) besser gewesen wäre, hätte auch die Speicherallokation
gespart. (Nur die Adresse wird kopiert)

Aber dann haette ich die Zahl wieder hinten dran gehabt, und auch haette
ich das Problem, dass evntl. die Laenge zu gross wird.

Wieso kann die Länge zu groß werden? Sind doch nur Zeiger. Im Normalfall
decken die die ersten 4GB auf jeden Fall ab. Sind sogar individuell, da
sparst Du Dir noch das getpid().

Naa. Ich meinte, die Groesse des Speicherfeldes koennte zu kein sein fuer ein
getpid() und den Namen davor.

Dann schreib das doch einfach ;-)

'\0' sind drei Buchstaben mehr *jammer* ;-)

Und ich dachte, ich wäre faul ;-)

Na hoer mal, ob ich '\0' tippe (Shift+#, Alt GR+ß, 0, Shift+#) oder ob ich nur
0 tippe, das ist ein grosser Unterschied ;-)

ANSI C sagt ja nur:

(stddef.h)
NULL which expands to an implementation-defined null pointer constant

In stddef.h steht dann auf meiner Maschine:

#define NULL ((void *)0)

Na gut. Solange das im Ergebnis einen falschen Ausdruck gibt (also einen
Ausdruck, der false ergibt), kann das meinetwegen eine Warnung geben.

(Eigentlich darf time() da keine Probleme machen. Ist meine Libc wirklich
so kaputt?)

Was fingerst du da auch drin rum? ;-)
Welches System eigentlich?

Och nö, geht mittlerweile. Arbeitet sauber.
Wenn der Code auch sauber ist! ,-)

Mittlerweile heisst?

[...]

Such Dir was aus, sind alle dort beschrieben ;-)

Ja, danke, das hab ich verdient. ;-)

Wieso?
Zugegeben, es mag vielleicht keine Loesung im C-Style sein. Aber sie ist
doch einfach und elegant?

Mpfffff...

Öh ...

Klarer Fall von Perl2C ;-)

Hoe?
Nein, mal im ernst, was hast du fuer Probleme mit der Loesung?

Reicht das denn nicht "at compile time"?
Mich ärgern hardcompiled paths ja auch unsäglich, aber hier?

Na, aber wie soll ich dann vorkompilierte Binaries anbieten? Waere ja geradezu
sinnlos.

Nein, ausnahmsweise richtig ;-)

[...]

Man, man, man. Ich habe noch gelernt, es gibt nur 0 (false) oder
ungleich 0 (true) und erst mit C++ sei bool eingefuehrt worden.

Gibt es einen Switch, der alle Warnungen ausgibt?

Nein, leider nicht. Mußt Du zusammenbauen, oder einen C Lint benutzen, z.B.
splint http://www.splint.org mit der Option -strict.

Danke.

Aber tu Dir das bloß nicht an! ;-)

Ich glaub, ich hab das oefter mal noetig ;-)

Warum meinst Du eigentlich, das eine PID bis zu 1024 Stellen haben
kann? Nur so als Frage ;-)

Wer sagt, dass ich das meine? ;-)
Ich verwende 'buff' noch etwas spaeter, als fread()-Buffer.

Wie ich schon weiter oben erwähnte:

Jaja, typisch perl2C ;-)

Hae? Erklaren Sie sich! ;-)

BTW:
stdio.h

• Macro: int BUFSIZ

[...]

Ja, ich weiss. Aber ich finde 1k-Bloecke irgendwie schoener ;-)

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Überprüfen Sie bitte Ihre Mitteilung! Sie ist zu lang (maximal 12288 Zeichen).

Ja sowas!

Hoehoe ;-) Fass dich halt kuerzer *g*

Liegt wohl daran, daß der Konqueror (2.2.2) die Tabs in je 8 Leerzeichen beim C&P in ein Textarea umwandelt. Nach Löschen derselben reichte es dann.
Naja, vielleicht doch mal auf 3.0.1 updaten ;-)

Ist ja nur noch getpid()

Ein eindeutiges Merkmal gibt es z.B. mit tmpnam() bzw tmpfile()

Oh, kannte ich auch noch nicht. Mal sehen, was die man-Page sagt:

BUGS
     These interfaces are provided for System V and ANSI compatibility only.
     The mkstemp(3) interface is strongly preferred.

[...]

Vor allen Dingen der erste Punkt macht mich stutzig; eine race condition kann
ich echt nicht brauchen. Weisst du naeheres darueber?

Nein, ich benutze sie auch nicht, da es hin und wieder (warum eigentlich wieder? Lernen die denn nicht aus ihren Fehlern? ;-) Bugs in den Implementationen gibt, speziell in der GNU-Libc.
Baue mir sowas dann immer selber. (meist mit einer Ck32 oder mk5 Checksum über das eigene Binary).
Ich glaueb aber immer noch daran, daß der Part überhaupt nicht nötig ist und gänzlich vermieden werden kann.
Habe aber leider erst heute Abend wieder Zeit. Werde mich dann näher mit dem Problem beschäftigen.

Kannst Dein malloc() an den meisten Stellen eh ganz weglassen.

Sicher, aber dann muesste ich mit festen Groessen arbeiten (Arrays), und
das moechte ich moeglichst vermeiden. So kann ich die Groesse ziemlich
genau bestimmen.

Nein, warum? Pointer reichen. Damit kann auch keine Ärger mit der Größe
auftauchen.

Bitte was?
Entschuldige, aber wie soll ich hier sonst einen String zusammensetzen? ;-)

Warum willst Du denn den String zusammensetzen?

und weder strcpy() noch strcat() sind eigentlich zu empfehlen.

Warum?

strcpy() weil in Deinem Fall tempfile = cfile (+ der danach notwendigen
Änderungen) besser gewesen wäre, hätte auch die Speicherallokation
gespart. (Nur die Adresse wird kopiert)

Aber dann haette ich die Zahl wieder hinten dran gehabt, und auch haette
ich das Problem, dass evntl. die Laenge zu gross wird.

Wieso kann die Länge zu groß werden? Sind doch nur Zeiger. Im Normalfall
decken die die ersten 4GB auf jeden Fall ab. Sind sogar individuell, da
sparst Du Dir noch das getpid().

Naa. Ich meinte, die Groesse des Speicherfeldes koennte zu kein sein fuer ein
getpid() und den Namen davor.

Nein, das brauchst Du nicht mehr. Der Wert des Pointers selber ist hier individuell.

Dann schreib das doch einfach ;-)

'\0' sind drei Buchstaben mehr *jammer* ;-)

Und ich dachte, ich wäre faul ;-)

Na hoer mal, ob ich '\0' tippe (Shift+#, Alt GR+ß, 0, Shift+#) oder ob ich nur
0 tippe, das ist ein grosser Unterschied ;-)

GCC nimmt auch ' (accent degue? Ich hatte kein Französisch, zumindest nicht als Sprache ;-) spart dann einen Tastenhieb ;-)

ANSI C sagt ja nur:

(stddef.h)
NULL which expands to an implementation-defined null pointer constant

In stddef.h steht dann auf meiner Maschine:

#define NULL ((void *)0)

Na gut. Solange das im Ergebnis einen falschen Ausdruck gibt (also einen
Ausdruck, der false ergibt), kann das meinetwegen eine Warnung geben.

Gibt jetzt trotz dem keine Warnung mehr. Habe ich mich wohl irgendwo vertippelt. Bitte entschuldige die unnötige Aufgeregtheit meinerseits.

(Eigentlich darf time() da keine Probleme machen. Ist meine Libc wirklich
so kaputt?)

Was fingerst du da auch drin rum? ;-)

Hab ich gar nicht! *heul* ;-)

Welches System eigentlich?

Linux 2.2.7cz (entspricht ungefähr 2.2.18 mit ein wenig aus der 2.4 Reihe) mit GLibc 2.0.undeinbischen

Die alte Glibc hinderte mich übrigens daran Mozilla 1.0.0 zu bauen (Die benutzen sendfile(), das gibt es erst seit 2.2.x und ich hatte noch keine Lust, es nachzubauen)

Och nö, geht mittlerweile. Arbeitet sauber.
Wenn der Code auch sauber ist! ,-)

Mittlerweile heisst?

Mittlere Optimierung (-O2 beim GCC) eigentlich schon seit den älteren egcs. Spätestens seit 2.95.2 ergibt auch -O3 keine Probleme mehr.
Selbst Dein von Dir so verabscheutes Loop Unrolling funktioniert tadellos ;-)

Wenn der Code sauber ist!
Keine schmutzigen Tricks, kein gar nichts, pures ANSI C!

[...]

Such Dir was aus, sind alle dort beschrieben ;-)

Ja, danke, das hab ich verdient. ;-)

Aber -O2 beim GCC muß immer gehen, sonst stimmt etwas im Code nicht.
Ja, es gibt mit Sicherheit auch Ausnahmen, aber mir fallen im Augenblick keine ein und ob Deine einfach gehaltenes (Nicht abschätzig gemeint! Beileibe nicht! Einfach ist seltenst schlecht!) Stückchen Code darunter fällt, wage ich doch ernsthaft zu bezweifeln.

Wieso?
Zugegeben, es mag vielleicht keine Loesung im C-Style sein. Aber sie ist
doch einfach und elegant?

Mpfffff...

Öh ...

Klarer Fall von Perl2C ;-)

Hoe?
Nein, mal im ernst, was hast du fuer Probleme mit der Loesung?

Diese Mehrfachbenutzung von Speicher für verschieden Typen ist typisch Perl. Da geht das nicht nur, da ist das durchaus sogar als geschickt anzusehen.
Hier aber nimmst Du dem Compiler die Möglichkeit einen einfachen Integer im Prozessorregister zu halten. Ein Geschwindigkeitsunterschied von etwa Faktor 1.000. Nur um 4 Byte zu sparen? Also, ich weiß ja nicht ;-)

Reicht das denn nicht "at compile time"?
Mich ärgern hardcompiled paths ja auch unsäglich, aber hier?

Na, aber wie soll ich dann vorkompilierte Binaries anbieten? Waere ja geradezu
sinnlos.

Achja, die vergesse ich immer. (Die einzigen Binaries hier sind eine alter Netscape und der Realplayer und die beiden laufen im chroot() Knast ;-)

Mmh...
Wie wäre es mit einer Environment Variablen?
getenv() ist ISO und auch schon bei Dir in Benutzung.
Und ein gutes Stück schneller, als die Dateihangelei!

Man, man, man. Ich habe noch gelernt, es gibt nur 0 (false) oder
ungleich 0 (true) und erst mit C++ sei bool eingefuehrt worden.

Auch erst seit C99, also ein gutes Stück nach C++.

splint http://www.splint.org mit der Option -strict.

Aber tu Dir das bloß nicht an! ;-)

Ich glaub, ich hab das oefter mal noetig ;-)

Dsa mag sein, aber bestimmt nicht mit der Option -strict. Da schmeißt selbst ein völlig korrektes "Hello World" Warnungen raus ;-)

#include <stdio.h>
#include <stdlib.h>

int main(void){
if ((printf("Hello World")) > 0 ){
 exit(EXIT_SUCCESS);
 }
else {exit(EXIT_FAILURE);}
}

bash-2.02$ splint -strict test.c
Splint 3.0.1.6 --- 16 Apr 2002

test.c: (in function main)
test.c:6:6: Called procedure printf may access file system state, but globals
               list does not include globals fileSystem
  A called function uses internal state, but the globals list for the function
  being checked does not include internalState (Use -internalglobs to inhibit
  warning)
test.c:6:6: Undocumented modification of file system state possible from call
               to printf: printf("Hello World")
  report undocumented file system modifications (applies to unspecified
  functions if modnomods is set) (Use -modfilesys to inhibit warning)

Finished checking --- 2 code warnings

Na, noch Fragen? ;-)))

Warum meinst Du eigentlich, das eine PID bis zu 1024 Stellen haben
kann? Nur so als Frage ;-)

Wer sagt, dass ich das meine? ;-)
Ich verwende 'buff' noch etwas spaeter, als fread()-Buffer.

Wie ich schon weiter oben erwähnte:

Jaja, typisch perl2C ;-)

Hae? Erklaren Sie sich! ;-)

Vieles, was bei Perl funktioniert, klappt auch in C.
Ist in C aber nicht immer und unbedingt von Vorteil ;-)

BTW:
stdio.h

• Macro: int BUFSIZ

[...]

Ja, ich weiss. Aber ich finde 1k-Bloecke irgendwie schoener ;-)

Gib dem Compiler doch die Möglichkeit zur Optimierung. BUFSIZ ist wirklich schon beim GLibc Bau genau auf die Möglichkeiten von Kernel und Architektur abgestimmt worden.
(ja, ich weiß: wer baut schon seine (G)Libc selber ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Moin,

Ich glaueb aber immer noch daran, daß der Part überhaupt nicht nötig ist und
gänzlich vermieden werden kann. Habe aber leider erst heute Abend wieder
Zeit. Werde mich dann näher mit dem Problem beschäftigen.

Ja, mach mal ;-) ich glaube das naemlich nicht *g*

Warum willst Du denn den String zusammensetzen?

Um einen Dateinamen zu bekommen, der Unique ist.

Nein, das brauchst Du nicht mehr. Der Wert des Pointers selber ist hier
individuell.

Ehm, wovon redest du eigentlich? Kann das sein, dass wir aneinander vorbei
reden? Oder du etwas abgelenkt bist? ;-)

Gibt jetzt trotz dem keine Warnung mehr. Habe ich mich wohl irgendwo
vertippelt.

*g*

Bitte entschuldige die unnötige Aufgeregtheit meinerseits.

Rechtfertigen Sie sich!!!1 ;-)

Och nö, geht mittlerweile. Arbeitet sauber.
Wenn der Code auch sauber ist! ,-)

Mittlerweile heisst?

Mittlere Optimierung (-O2 beim GCC) eigentlich schon seit den älteren egcs.
Spätestens seit 2.95.2 ergibt auch -O3 keine Probleme mehr.
Selbst Dein von Dir so verabscheutes Loop Unrolling funktioniert tadellos ;-)

Das hat nichts mit 'verabscheuen' zu tun ;-) ich bin einfach sehr misstrauisch
dem gegenueber. Eigentlich misstrauisch gegenueber saemtlichen
Code-Aenderungen durch Fremd-Eingriffe.

Aber -O2 beim GCC muß immer gehen, sonst stimmt etwas im Code nicht.
Ja, es gibt mit Sicherheit auch Ausnahmen, aber mir fallen im Augenblick
keine ein und ob Deine einfach gehaltenes (Nicht abschätzig gemeint!
Beileibe nicht! Einfach ist seltenst schlecht!) Stückchen Code darunter
fällt, wage ich doch ernsthaft zu bezweifeln.

Ich auch. Ich hatte es ueberigens sicher nicht abschaetzig verstanden -- ich
weiss selber, dass der Code einfach ist ;-)

Diese Mehrfachbenutzung von Speicher für verschieden Typen ist typisch Perl.

Wo nutze ich den Speicher fuer verschiedenen Typen?

Da geht das nicht nur, da ist das durchaus sogar als geschickt anzusehen.
Hier aber nimmst Du dem Compiler die Möglichkeit einen einfachen Integer im
Prozessorregister zu halten. Ein Geschwindigkeitsunterschied von etwa
Faktor 1.000. Nur um 4 Byte zu sparen? Also, ich weiß ja nicht ;-)

Wuerdest du mir mal aufzeigen, was du meinst?

Achja, die vergesse ich immer. (Die einzigen Binaries hier sind eine alter
Netscape und der Realplayer und die beiden laufen im chroot() Knast ;-)

Ich habe keine einzige Vorkompilierte Binary auf dem System *g*

Mmh...
Wie wäre es mit einer Environment Variablen?
getenv() ist ISO und auch schon bei Dir in Benutzung.
Und ein gutes Stück schneller, als die Dateihangelei!

Eine gute Idee und recht einfach ueber Apache-Konfigs zu erreichen. Mal drueber
nachdenken...

Man, man, man. Ich habe noch gelernt, es gibt nur 0 (false) oder
ungleich 0 (true) und erst mit C++ sei bool eingefuehrt worden.

Auch erst seit C99, also ein gutes Stück nach C++.

Ja, sag ich ja. Ich habe es noch anders gelernt.

[... splint ...]
Na, noch Fragen? ;-)))

Noe ;-)

Gib dem Compiler doch die Möglichkeit zur Optimierung. BUFSIZ ist wirklich
schon beim GLibc Bau genau auf die Möglichkeiten von Kernel und Architektur
abgestimmt worden.
(ja, ich weiß: wer baut schon seine (G)Libc selber ;-)

Na schoen, ueberzeugt ;-)

Gruesse,
 CK

[Michael Schröpl]

Hallo Christian,

Wie wäre es mit einer Environment Variablen?
Eine gute Idee und recht einfach ueber Apache-
Konfigs zu erreichen. Mal drueber nachdenken...

1. zusätzliche Abhängigkeit von mod_env.
2. SetEnv geht zwar in .htaccess, erfordert aber ggf.
   zusätzliches AllowOverride. Da gibt es leider keine
   vollständige Tabelle in der Apache-Dokumentation,
   welche Direktive in welcher Override-Klasse liegt.)
Und letzteres kann der Anwender ziemlich sicher _nicht_
selbst beeinflussen.

Ich finde die Konfigurationsdatei auch nicht optimal
(zumal sie sicherlich Maschinenlast kostet), aber ich
weiß auch nicht recht, ob ich auf sie verzichten würde.
Es gibt sicher viele Anwender in der Zielgruppe, die
keinen C-Compiler haben (oder sogar nicht mal shell-
Zugang zur Zielmaschine).

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.ico" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Wie wäre es mit einer Environment Variablen?
Eine gute Idee und recht einfach ueber Apache-
Konfigs zu erreichen. Mal drueber nachdenken...

1. zusätzliche Abhängigkeit von mod_env.
2. SetEnv geht zwar in .htaccess, erfordert aber ggf.
      zusätzliches AllowOverride. Da gibt es leider keine
      vollständige Tabelle in der Apache-Dokumentation,
      welche Direktive in welcher Override-Klasse liegt.)
   Und letzteres kann der Anwender ziemlich sicher _nicht_
   selbst beeinflussen.

Und ich hatte mich schon so gefreut, endlich mal eine gute Idee gehabt zu haben.
*sniff*
;-)

Ich finde die Konfigurationsdatei auch nicht optimal
(zumal sie sicherlich Maschinenlast kostet), aber ich
weiß auch nicht recht, ob ich auf sie verzichten würde.
Es gibt sicher viele Anwender in der Zielgruppe, die
keinen C-Compiler haben (oder sogar nicht mal shell-
Zugang zur Zielmaschine).

Ich glaube, das gehört beides zusammen. Leute die einen Shellzugang haben, bekommen auch meistens Compilerzugang. Umgekehrt wäre ein shellzugang sogar zwingend. Ansonsten wäre der Compiler recht kompliziert zu bedienen ;-)

Für den Rest gibt es ja immer noch die Perl-Version.

BTW: welcher Geschwindigkeitsunterschied besteht eigentlich? Schonmal genauer probiert?

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Und ich hatte mich schon so gefreut, endlich mal
eine gute Idee gehabt zu haben.

ich bin keineswegs sicher, daß das nicht doch eine
gute Idee ist. Ich habe einfach nur noch nicht aus-
probiert, _ob_ SetEnv in .htaccess irgend ein
AllowOverride erfordert (und wenn ja, welches) -
nur in die Doku geschaut und dort nichts gefunden.
Vielleicht ist das wirklich die beste Lösung - denn
eine Einbindung des Handlers via .htaccess braucht
man ja ohnehin, da könnte man das SetEnv gleich mit
erledigen.
Meine Perl-Version hat für dieses Wurzelverzeichnis
einen Default-Wert relativ zum DOCUMENT_ROOT, falls
der Benutzer nichts gesetzt hat ... der liegt dann
allerdings innerhalb des URL-Baums, was ich auch nicht
so ganz geschickt finde. Aber wo sonst könnte ich per
Default Schreibrecht vermuten? (_Nicht_ /tmp etc.,
weil das Ding ja multi-customer-fähig sein soll, für
Massenprovider-Webspaces.)

BTW: welcher Geschwindigkeitsunterschied besteht
eigentlich? Schonmal genauer probiert?

Im Moment denke ich nicht mal, daß beide Versionen
exakt dasselbe tun - gzip_cnc und gzip_cncc sind da
ein wenig auseinander gelaufen (auch bezüglich ihrer
Versionsnummern). Deshalb steht in meiner Doku ja auch
"Reimplementierung" und nicht "Portierung" drin.

Außerdem hängt das vermutlich dramatisch von Randbe-
dingungen ab, die das Programm nicht selbst zu ver-
antworten hat: Auf meinem AMD 800 mit Win98, ActivePerl
via CGI und Apache 1.3.23 ist gzip_cnc beispielsweise
_viel_ langsamer (Faktor 4) als auf dem Pentium 400
meines Providers mit Suse Linux, Apache 1.3.12, aber
mod_fastcgi ... auf meiner Win-Plattform konnte ich
Compress::Zlib gegen system(gzip.exe) testen, aber
keinen deutlichen Geschwindigkeitsunterschied messen.

Absolute Zahlen in meinem gzip_cnc-Logfile (online):
Um die 0.04 CPU-sec pro Zugriff bei reiner Ausliefe-
rung (unabhängig von der Dokumentgröße), die Kompri-
mierung kleiner Dokumente (10-20 KB) merkt man prak-
tisch nicht zusätzlich, bei großen Dokumenten (400 KB)
geht die Rechenzeit auf 0.15 CPU-sec hoch (alles auf
der alten Suse-Maschine).

Die C-Version habe ich noch nicht selbst laufen lassen

• und ich weiß auch nicht, welches Äquivalent für Perl
  "times()" die in ihrem logfile zu bieten hätte.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.ico" border=0 alt=""> Michael

[Michael Schröpl]

Hi Christoph,

Wie wäre es mit einer Environment Variablen?

herzlichen Glückwunsch zur guten Idee! :-)

In der Tat setzt SetEnv eine AllowOverride-Einstellung
voraus - und zwar die vom Typ "FileInfo".

Das ist aber kein Problem - denn die braucht gzip_cnc
sowieso, weil es sonst nicht via "Action" als Handler
eingebunden werden kann!

Die Konfigurationsdatei scheint also entbehrlich zu
sein ... hm - da muß ich mir ja fast überlegen, ob ich
das nicht auch für die Perl-Version nutzen sollte,
wenn man auf diese Weise den Perl-Code unangetastet
lassen kann ... mod_env selbst dürfte ja praktisch
überall installiert sein ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.ico" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

und da wollt' ich gerade zu Bette gehen ;-)

Wie wäre es mit einer Environment Variablen?

In der Tat setzt SetEnv eine AllowOverride-Einstellung
voraus - und zwar die vom Typ "FileInfo".

Das ist aber kein Problem - denn die braucht gzip_cnc
sowieso, weil es sonst nicht via "Action" als Handler
eingebunden werden kann!

Aha!
Na, dannn: nix wie reingebaut und schon wieder ein malloc() und ein komplettes Filehandling gespart ;-)

...

done ;-)

Händisches Diff:

Ab 655:

• char *file = getenv("PATH_TRANSLATED"), *cfgname;

• char *file = getenv("PATH_TRANSLATED"), *cfgname, *cpname;
      struct stat gz, org;
      FILE *base;
      size_t rlen;

/*
     * find my config file
     */
    /*CZ may have been set as en environment variable */

cpname = getenv("GZIP_CNCC_CACHE_PATH");

if(!cpname) {

[...]

[ das ganze Geraffel bis ]

if (CACHE_PATH[rlen - 1] == '\n') {
 CACHE_PATH[rlen - 1] = '\0';
    }

} /* if(!cpname) */

/*CZ2CK CACHE_PATH is limited to 255 chars. is that really sufficient?
     *CZ2CK CACHE_PATH should also be a pointer. snprintf() is much ado for
     *CZ2CK a simple pathname ;-) */

snprintf(CACHE_PATH, (size_t)(256),"%s",cpname);

Vorsicht: noch nicht getestet!

Die Konfigurationsdatei scheint also entbehrlich zu
sein ... hm - da muß ich mir ja fast überlegen, ob ich
das nicht auch für die Perl-Version nutzen sollte,
wenn man auf diese Weise den Perl-Code unangetastet
lassen kann ... mod_env selbst dürfte ja praktisch
überall installiert sein ...

Geh ich mal von aus. Ist einfach _zu_ praktisch sowas.

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

lassen kann ... mod_env selbst dürfte ja praktisch
überall installiert sein ...
Geh ich mal von aus. Ist einfach _zu_ praktisch sowas.

ich meinte eher: Die Provider sind bestimmt zu faul,
das extra auszubauen ... ;-)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Calocybe]

Moin moin!

In der Tat setzt SetEnv eine AllowOverride-Einstellung
voraus - und zwar die vom Typ "FileInfo".

Gleich mal in Vorbereitung auf die vielen Supportanfragen, die Du dann sicher bekommen wirst, sei darauf hingewiesen, dass SetEnv innerhalb von .htaccess erst seit Apache 1.3.7 moeglich ist (einige Provider haben ja durchaus noch aeltere Installationen laufen), diese Moeglichkeit jedoch erst seit 1.3.23 odr .24 dokumetiert ist. In meiner .22-Doku steht's naemlich noch nicht drin (http://docserv.calocybe.dyndns.org/manuals/apache-1.3.22/mod/mod_env.html).

So long

--
Invest in America - Buy a Congressman!
    -- a slogan from http://www.evolvefish.com/

[Christoph Zurnieden]

Hallo,

Ich glaueb aber immer noch daran, daß der Part überhaupt nicht nötig ist und
gänzlich vermieden werden kann. Habe aber leider erst heute Abend wieder
Zeit. Werde mich dann näher mit dem Problem beschäftigen.

Ja, mach mal ;-) ich glaube das naemlich nicht *g*

Das ist kein theologischer Disput hier! ;-)

Bin aber gerade erst nach Hause gekommen. Das mit "heute Abend" muß ich leider wiederholen ;-)

Warum willst Du denn den String zusammensetzen?

Um einen Dateinamen zu bekommen, der Unique ist.

Aha. Und dafür dieser Riesenaufwand?

Nein, das brauchst Du nicht mehr. Der Wert des Pointers selber ist hier
individuell.

Ehm, wovon redest du eigentlich? Kann das sein, dass wir aneinander vorbei
reden?

Das ist durchaus möglich ;-)

Oder du etwas abgelenkt bist? ;-)

Leider nicht *sigh* ;-)

Bitte entschuldige die unnötige Aufgeregtheit meinerseits.

Rechtfertigen Sie sich!!!1 ;-)

Nö.
Pah!
;-)

Mittlere Optimierung (-O2 beim GCC) eigentlich schon seit den älteren egcs.
Spätestens seit 2.95.2 ergibt auch -O3 keine Probleme mehr.
Selbst Dein von Dir so verabscheutes Loop Unrolling funktioniert tadellos ;-)

Das hat nichts mit 'verabscheuen' zu tun ;-) ich bin einfach sehr misstrauisch
dem gegenueber. Eigentlich misstrauisch gegenueber saemtlichen
Code-Aenderungen durch Fremd-Eingriffe.

Du hast den Code Deines Compilers und damit Gelegenheit ihn zu überprüfen.

Diese Mehrfachbenutzung von Speicher für verschieden Typen ist typisch Perl.

Wo nutze ich den Speicher fuer verschiedenen Typen?

Im angesprochenem Part. Einmal pid_t und einmal char. Deshalb mußtest Du auch sprintf() zwecks Umwandlung bemühen.

Da geht das nicht nur, da ist das durchaus sogar als geschickt anzusehen.
Hier aber nimmst Du dem Compiler die Möglichkeit einen einfachen Integer im
Prozessorregister zu halten. Ein Geschwindigkeitsunterschied von etwa
Faktor 1.000. Nur um 4 Byte zu sparen? Also, ich weiß ja nicht ;-)

Wuerdest du mir mal aufzeigen, was du meinst?

getpid() gibt pid_t zurück. Das ist ein Integer (nicht unbedingt ein int, aber ein Integerwert). Den kann man direkt in ein Register packen (auch zwingen durch "register int", ist aber nicht sehr zuverlässig).
Du packst den aber nach ganz oben. Wozu?

Achja, die vergesse ich immer. (Die einzigen Binaries hier sind eine alter
Netscape und der Realplayer und die beiden laufen im chroot() Knast ;-)

Ich habe keine einzige Vorkompilierte Binary auf dem System *g*

Den alten Netscape (ist ein 4.05) brauche ich zur Kontrolle bei CSS. Bin meist zu faul ein @ einzubauen ;-)
Außerdem spielt aus irgendwelche Gründen OpenSSL nicht mit MS Software zusammen. (z.B. Ebay ;-)

Der Realplayer brauche ich, ... äh ..., nunja, ...öh ..., mag ich jetzt nicht sagen ;-)

Mmh...
Wie wäre es mit einer Environment Variablen?
getenv() ist ISO und auch schon bei Dir in Benutzung.
Und ein gutes Stück schneller, als die Dateihangelei!

Eine gute Idee und recht einfach ueber Apache-Konfigs zu erreichen. Mal drueber
nachdenken...

Na, ist zwar selten, aber manchmal hab' ich auch mal eine gute Idee ;-)

so short

Christoph Zurnieden

[Calocybe]

Moin moin!

Warum willst Du denn den String zusammensetzen?
Um einen Dateinamen zu bekommen, der Unique ist.
Aha. Und dafür dieser Riesenaufwand?
Nein, das brauchst Du nicht mehr. Der Wert des Pointers selber ist hier
individuell.
Ehm, wovon redest du eigentlich? Kann das sein, dass wir aneinander vorbei
reden?
Das ist durchaus möglich ;-)

Ich bin mir nicht sicher, ob ich verstanden habe, was Du geschrieben hast. Ich hab das ganze auch nur mehr oder weniger ueberflogen. Ein Posting vorher sah es fuer mich noch so aus, wie wenn Du vorschlaegst, den Wert eines Pointers (auf int gecastet) zur Bildung eines system-global eindeutigen Dateinamens heranzuziehen. In diesem Posting sieht's aber nicht mehr so aus, wie wenn Du diese Idee verfolgst. Hattest Du das nun so gemeint oder nicht?

So long

--
Invest in America - Buy a Congressman!
    -- a slogan from http://www.evolvefish.com/

[Christoph Zurnieden]

Hallo,

Warum willst Du denn den String zusammensetzen?
Um einen Dateinamen zu bekommen, der Unique ist.
Aha. Und dafür dieser Riesenaufwand?
Nein, das brauchst Du nicht mehr. Der Wert des Pointers selber ist hier
individuell.
Ehm, wovon redest du eigentlich? Kann das sein, dass wir aneinander vorbei
reden?
Das ist durchaus möglich ;-)

Ich bin mir nicht sicher, ob ich verstanden habe, was Du geschrieben hast. Ich hab das ganze auch nur mehr oder weniger ueberflogen. Ein Posting vorher sah es fuer mich noch so aus, wie wenn Du vorschlaegst, den Wert eines Pointers (auf int gecastet)

(Wenn dann: unsigned int ;-)

zur Bildung eines system-global eindeutigen Dateinamens heranzuziehen.

Das geht natürlich nicht. Der wäre dann nur lokal und nur at Runtime einmalig.

In diesem Posting sieht's aber nicht mehr so aus, wie wenn Du diese Idee verfolgst. Hattest Du das nun so gemeint oder nicht?

Da er die URIs abbildet, also im Cache Verzeichniss am Ende der Verzeichnisbaum abgebildet ist, sind die Dateinamen eh eindeutig (sind ja erstens nur statische Seiten und zweitens kann das durchaus bei komplizierten Pfadumbauten seitens des Apachen auch in die Hose gehen ;-).
Also reicht rein theoretisch auch ein stinknormales Präfix, da fest sein darf und per sprintf() o.ä. vorgehangen wird.

Bei EEXIST evt halt noch mehrmals, sollte aber nur bei besonders bösen Pfadumbauten vom Apachen vorkommen, wenn überhaupt.

Ist aber auch nichts halbes und nichts ganzes. Würde den komprimierten String in Memory halten, senden und dann erst in eine Datei schreiben.
Das verhindert auch Synchronisationsprobleme und ist schnell.

Globale, ja selbst nur lokale eindeutige Dateinamen zu finden ist schwierig. Da sollte eigentlich tmpfile() bzw tmpname() für einspringen. Die sind aber laut ISO nur für mindestens 25 Datei(nam)en (TMP_MAX) garantiert und haben hin und wieder Bugs in den Implementationen.

Das eigentliche Problem ist ja das nicht ANSI konforme getpid().
Ließe sich höchstens bei Fallenlassen der ANSI Kompatibilität durch einen Test auf POSIX begründen.

#ifndef __STRICT_ANSI /* GCC schaltet das ein, wenn -ansi gefordert wird */
#ifdef _POSIX_SOURCE
getpid()
#endif
#else
tmpname()
#endif

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo ihr beiden,

Ein Posting vorher sah es fuer mich noch so aus,
wie wenn Du vorschlaegst, den Wert eines Pointers
(auf int gecastet) zur Bildung eines system-
global eindeutigen Dateinamens heranzuziehen.
Das geht natürlich nicht. Der wäre dann nur lokal
und nur at Runtime einmalig.

der Dateiname muß auch nur während der Laufzeit des
Programms eindeutig sein - das ist ja eine temporäre
Datei, die anschließend auf ihren endgültigen Namen
innerhalb des Cache umbenannt wird.
Wobei wir das Umbenennen als "hinreichend unteilbar"
angenommen haben - zumal es egal wäre, wenn ein zwei-
ter Prozeß das Ergebnis eines vorherigen überschreibt:
Bei der Komprimierung werden ja nicht semantisch ver-
schiedene Ergebnisse heraus kommen.

Insofern erfüllt die $PID semantisch betrachtet genau
das, was wir erreichen wollten ... es könnte jedoch
durchaus sein, daß ein absoluter (!) Adreßraumpointer
dieselben Eigenschaften könnte. Ein relativer (bei
einem Betriebssystem mit virtuellem Adreßraum) dagegen
würde wohl nicht reichen, denke ich.

Da er die URIs abbildet, also im Cache Verzeichnis
am Ende der Verzeichnisbaum abgebildet ist, sind die
Dateinamen eh eindeutig (sind ja erstens nur
statische Seiten und zweitens kann das durchaus bei
komplizierten Pfadumbauten seitens des Apachen auch
in die Hose gehen ;-).

Das habe ich jetzt nicht wirklich verstanden.

Der Cache-Baum repräsentiert _nicht_ den Dateibaum,
sondern den URI-Baum - es kann also bei entsprechenden
URL-Mappings durchaus vorkommen, daß dasselbe Dokument
mehrfach im Cache herumliegt. Das kommt m. E. aber
selten vor - seltener jedenfalls, als daß _überhaupt_
Mappings verwendet werden. Daß der URL-Raum auf
mehrere Datei-Teilbäume verteilt sein kann, damit
wollte ich fertig werden können.
Und ich wollte _eine_ Wurzel des Cache-Baums haben,
ohne dafür die Wurzel des gesamten Verzeichnisbaums zu
verwenden ... das wäre auch gegangen, hätte aber
längere Pfadnamen zur Folge gehabt.

Ist aber auch nichts halbes und nichts ganzes.
Würde den komprimierten String in Memory halten,
senden und dann erst in eine Datei schreiben.
Das verhindert auch Synchronisationsprobleme und
ist schnell.

Die Komprimierung wird (hoffentlich) so selten auf-
gerufen, daß dies (was wir durchaus auch in Erwägung
gezogen hatten) im Schnitt über alle Zugriffe kaum
eine Beschleunigung bringen würde.

Komprimieren im Hauptspeicher war bei meiner ersten
Perl-Implementierung (unter Verwendung von /bin/gzip)
gar nicht möglich und ist es auf meiner Domain (wo
kein Compress::Zlib installiert ist) auch jetzt noch
nicht. Zudem würde es mehr Speicher kosten, ohne
dafür eine nennenswerte Beschleunigung zu bewirken ...
Compress::Zlib würde eine in-memory-Komprimierung
bieten, aber ich sehe im Moment wenig Sinn darin.

Ich sehe auch nicht, wie das Komprimieren im RAM
Synchronisationsprobleme verhindern würde.
Irgendwann muß das Ergebnis der Komprimierung in
die Cache-Datei geschrieben werden - und dazu ist
entweder eine explizite Synchronisation notwendig,
falls gleich in die endgültige Datei geschrieben
werden soll (und nachfolgende lesende Cache-Zugriffe
müssen damit ebenfalls umgehen können) oder eben
die Trivial-Methode, nur fertige Dateien durch Umbe-
nennung um Cache "sichtbar" für andere Zugriffe zu
machen.

Globale, ja selbst nur lokale eindeutige Dateinamen
zu finden ist schwierig. Da sollte eigentlich
tmpfile() bzw tmpname() für einspringen.

In unserem Falle reicht es, $PID an den späteren
Namen der Cache-Datei anzuhängen. Im Cache gibt es
nur Dateien, die auf ".gz" enden, und solche tempo-
räre Dateien, die über ihre Endung unique sind.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Ein Posting vorher sah es fuer mich noch so aus,
wie wenn Du vorschlaegst, den Wert eines Pointers
(auf int gecastet) zur Bildung eines system-
global eindeutigen Dateinamens heranzuziehen.
Das geht natürlich nicht. Der wäre dann nur lokal
und nur at Runtime einmalig.

der Dateiname muß auch nur während der Laufzeit des
Programms eindeutig sein - das ist ja eine temporäre
Datei, die anschließend auf ihren endgültigen Namen
innerhalb des Cache umbenannt wird.

Ja, das ist bekannt. Wollte nur darauf hinweisen, das _global_ eindeutig identifizierbare Namen ein kaum lösbares Problem darstellen.
War wohl etwas ungenauer formuliert als sowieso schon beabsichtigt ;-)

Wobei wir das Umbenennen als "hinreichend unteilbar"
angenommen haben - zumal es egal wäre, wenn ein zwei-
ter Prozeß das Ergebnis eines vorherigen überschreibt:

Stimmt auch mal wieder. Habe ich jetzt nicht bedacht.
Sollte sich über einen Index eigentlich bequem lösen lassen.
Aber ob sich das rechnen würde wage ich dann doch arg zu bezweifeln.
Also lieber die eine oder andere Überschreibung riskieren.

Bei der Komprimierung werden ja nicht semantisch ver-
schiedene Ergebnisse heraus kommen.

Wollen's hoffen ;-)

Insofern erfüllt die $PID semantisch betrachtet genau
das, was wir erreichen wollten ... es könnte jedoch
durchaus sein, daß ein absoluter (!) Adreßraumpointer
dieselben Eigenschaften könnte. Ein relativer (bei
einem Betriebssystem mit virtuellem Adreßraum) dagegen
würde wohl nicht reichen, denke ich.

Nein, noch nicht einmal ein absoluter.
Es wird aber sowieso umbenannt. Der endgültige Name folgt einer bekannten Gesetzgebung (sonst könnte er ja nicht gefunden werde, gelle? ;-).
Warum also wird überhaupt ein derart streng definierter Identifikator gesucht?
Alles, was nicht dem endgültigem Schema entspricht, ist also schonmal eine temporäre Datei. Der Name der temporären Datei, die geschrieben werden soll, ist auch innerhalb des jeweiligen Prozesses bekannt.
Warum also nicht mittels Registern eine Nummer verarbeiten und die anhängen?
Bei Rückgabe von EEXIST wird halt einfach um 123 incriminiert.
Auf EEXIST muß sowieso geprüft werden, da auch eine PID im Laufe eines Serverlebens mehrfach (halt nur nie gleichzeitig) auftauchen kann.
(Wenn man mal davon absieht, das Überschreiben akzeptabel sei)

Allerdings habe ich mich da gerade völlig verwurschtelt. Ich wollte doch die Zusammenbastelei vermeiden. Du hast mich hier völlig aus dem Konzept gebracht! ;-)

Gut: das ganze läuft wie folgt (bzw sollte so funktionieren ;-):

gzip_cncc bekommt einen Dateinamen der übertragen werden soll.
Der wird geprüft, ob er überhaupt vorhanden ist. if false -> 404
Wenn tatsächlich vorhanden, wird geprüft, ob evt schon eine komprimierte Version vorhanden ist if true -> send cached-file
Wenn keine da ist, wird der Kompressionsmechanismus angeworfen.

Temporäre Datei erzeugt. Angeforderte Datei komprimiert in das Tempfile
Umbenennen des Tempfiles in ein reguläres Cachefile nach Muster.

Name des Tempfiles  = Cachefile  + lokaler Identifikator (PID)
Name des Cachefiles = Cache-Pfad + Originaldateiname + ".gz"

Mir ist immer noch nicht ganz eingängig, warum beim Tempfile ein _ein_deutiger Identifikator da sein muß.
Besser wäre es doch, in einem Temdir die Dateien mit richtigem und vollständigem Namen abzulegen, sodaß ein EEXIST die Mehrfachüberschreibung im Keime erstickt.
(In dem Falle -> send-orig-file für alle, die ein EEXISTS bei der Komprimierung erwischt.)
Also komprimiert immer nur der erste gzip_cncc Prozess die Datei und belastet den Prozessor und das Dateisystem. Der Rest arbeitet ganz normal.

Ich glaube, daß so die Zeit bis zum erstem möglichem Cachezugriff deutlich verkürzt wird.
Denn wenn eine Datei noch nicht im Cache liegt, wird sie von jedem gzip_cncc Prozess in die Mangel genommen, der die Anfrage auf die gleiche Datei bekommt solange sie noch nicht im Cache auftaucht.

Da er die URIs abbildet, also im Cache Verzeichnis
am Ende der Verzeichnisbaum abgebildet ist, sind die
Dateinamen eh eindeutig (sind ja erstens nur
statische Seiten und zweitens kann das durchaus bei
komplizierten Pfadumbauten seitens des Apachen auch
in die Hose gehen ;-).

Das habe ich jetzt nicht wirklich verstanden.

Nicht nur kompliziert Pfadumbauten, auch verzwickte Grammatik ;-)
Aber ich kann Dich beruhigen, Du hast das Problem durchaus erkannt.

Der Cache-Baum repräsentiert _nicht_ den Dateibaum,
sondern den URI-Baum - es kann also bei entsprechenden
URL-Mappings durchaus vorkommen, daß dasselbe Dokument
mehrfach im Cache herumliegt.

Ich hatte eher den Umstand im Auge, das evt derselbe Datei_name_ mehrfach in den Cache geschickt wird ;-)

Das kommt m. E. aber
selten vor - seltener jedenfalls, als daß _überhaupt_
Mappings verwendet werden. Daß der URL-Raum auf
mehrere Datei-Teilbäume verteilt sein kann, damit
wollte ich fertig werden können.

Da sehe ich auch gar kein Problem drin.

Und ich wollte _eine_ Wurzel des Cache-Baums haben,
ohne dafür die Wurzel des gesamten Verzeichnisbaums zu
verwenden ... das wäre auch gegangen, hätte aber
längere Pfadnamen zur Folge gehabt.

Hätte auch keine große Rolle gespielt. Die maximal möglichen Dateinamen (incl Pfad) sind bei den jetzigen Systemen auf 4096 begrenzt. Das ist bei den gängigen Architekturen genau ein Page. Verlahmung (schönes Wort, leider nichtz von mir ;-) durch Speicherfragmentierung sollte also kein großes Problem darstellen.
FILENAME_MAX enthält die entsprechende Zahl (Ist ANSI, muß also vorkommen)

Ist aber auch nichts halbes und nichts ganzes.
Würde den komprimierten String in Memory halten,
senden und dann erst in eine Datei schreiben.
Das verhindert auch Synchronisationsprobleme und
ist schnell.

Die Komprimierung wird (hoffentlich) so selten auf-
gerufen, daß dies (was wir durchaus auch in Erwägung
gezogen hatten) im Schnitt über alle Zugriffe kaum
eine Beschleunigung bringen würde.

War mir jetzt nicht um Geschwindigkeit, sondern eher um Einfachheit ;-)

Komprimieren im Hauptspeicher war bei meiner ersten
Perl-Implementierung (unter Verwendung von /bin/gzip)
gar nicht möglich und ist es auf meiner Domain (wo
kein Compress::Zlib installiert ist) auch jetzt noch
nicht. Zudem würde es mehr Speicher kosten, ohne
dafür eine nennenswerte Beschleunigung zu bewirken ...
Compress::Zlib würde eine in-memory-Komprimierung
bieten, aber ich sehe im Moment wenig Sinn darin.

Es ist bedeutend simpler.

Ich sehe auch nicht, wie das Komprimieren im RAM
Synchronisationsprobleme verhindern würde.
Irgendwann muß das Ergebnis der Komprimierung in
die Cache-Datei geschrieben werden - und dazu ist
entweder eine explizite Synchronisation notwendig,
falls gleich in die endgültige Datei geschrieben
werden soll (und nachfolgende lesende Cache-Zugriffe
müssen damit ebenfalls umgehen können)

Ja gut, das Argument muß ich gelten lassen.
Ein Locking Mechanismus würden die Simplizität wieder ruinieren ;-)

oder eben
die Trivial-Methode, nur fertige Dateien durch Umbe-
nennung um Cache "sichtbar" für andere Zugriffe zu
machen.

Na, _so_ trivial ist sie ja auch nicht ,-)

Globale, ja selbst nur lokale eindeutige Dateinamen
zu finden ist schwierig. Da sollte eigentlich
tmpfile() bzw tmpname() für einspringen.

In unserem Falle reicht es, $PID an den späteren
Namen der Cache-Datei anzuhängen. Im Cache gibt es
nur Dateien, die auf ".gz" enden, und solche tempo-
räre Dateien, die über ihre Endung unique sind.

getpid() ist ja leider nicht in ANSI C.
Darum ging es ja im Grunde genommen.

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Es wird aber sowieso umbenannt. Der endgültige Name
folgt einer bekannten Gesetzgebung (sonst könnte er
ja nicht gefunden werde, gelle? ;-).
Warum also wird überhaupt ein derart streng
definierter Identifikator gesucht?

weil das Erzeugen des komprimierten Inhalts signifikant
länger dauert als das Umbenennen des Ergebnisses.
Die Wahrscheinlichkeit für eine Kollision beim Kompri-
mieren ist viel höher als diejenige beim Umbenennen -
und die letztere soll gefälligst das Betriebssystem
behandeln.

Auf EEXIST muß sowieso geprüft werden, da auch eine
PID im Laufe eines Serverlebens mehrfach (halt nur
nie gleichzeitig) auftauchen kann.

Kann sie - wirklich?

Mir ist immer noch nicht ganz eingängig, warum beim
Tempfile ein _ein_deutiger Identifikator da sein
muß.
Besser wäre es doch, in einem Temdir die Dateien mit
richtigem und vollständigem Namen abzulegen, sodaß
ein EEXIST die Mehrfachüberschreibung im Keime
erstickt.

Ich traue dem EEXIST nicht.
Ich traue überhaupt keinem trivialen Mechanismus zur
Synchronisation. Ein

if (! EEXIST)
      { create zipped file }

kann genau in dem Moment platzen, wenn nach dem "if"
ein Prozeßwechsel statt findet und der andere gzip-
Prozeß ebenfalls in die kritische Zone hinein läuft.

Da ist meine Hoffnung, daß dasselbe Problem innerhalb
des Betriebsystemkommandos für die Umbenennung einer
Datei zuverlässiger gelöst ist, als ich das könnte,
doch erheblich.

Also komprimiert immer nur der erste gzip_cncc
Prozess die Datei und belastet den Prozessor und
das Dateisystem. Der Rest arbeitet ganz normal.

Der Fall der Kollision ist so selten, daß er in Sachen
CPU-Belastung irrelevant ist.
In Sachen Datenkonsistenz ist er es nicht, da die kom-
primierte Datei anschließend beliebig oft gelesen wer-
den könnte.

Ich hatte eher den Umstand im Auge, das evt derselbe
Datei_name_ mehrfach in den Cache geschickt wird ;-)

Ich auch (falls derselbe Dateiname über entsprechende
Alias-Mappings auf mehrer URLs abgebildet wird, haben
wir halt ein bißchen Redundanz im Cache).

Und ich wollte _eine_ Wurzel des Cache-Baums haben,
ohne dafür die Wurzel des gesamten Verzeichnisbaums zu
verwenden ... das wäre auch gegangen, hätte aber
längere Pfadnamen zur Folge gehabt.
Hätte auch keine große Rolle gespielt.

Es geht mir hier auch um die usability.
Ich selbst habe beim Testen immer wieder in den Cache
geschaut, um zu prüfen, ob alles so tut, wie es sollte.
Das wird den Benutzern, die gzip_cnc installieren,
möglicherweise ähnlich gehen - und in diesem Falle ist
ein "kurzer" Pfadname angenehm.

die Trivial-Methode, nur fertige Dateien durch Umbe-
nennung um Cache "sichtbar" für andere Zugriffe zu
machen.
Na, _so_ trivial ist sie ja auch nicht ,-)

"rename" hat sich bei ähnlichen Fällen bewährt - ich
mache das seit vielen Jahren so. (Deshalb weiß ich
auch gar nicht, wie "flock" funktioniert ... ;-)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Es wird aber sowieso umbenannt. Der endgültige Name
folgt einer bekannten Gesetzgebung (sonst könnte er
ja nicht gefunden werde, gelle? ;-).
Warum also wird überhaupt ein derart streng
definierter Identifikator gesucht?

weil das Erzeugen des komprimierten Inhalts signifikant
länger dauert als das Umbenennen des Ergebnisses.
Die Wahrscheinlichkeit für eine Kollision beim Kompri-
mieren ist viel höher als diejenige beim Umbenennen -
und die letztere soll gefälligst das Betriebssystem
behandeln.

Da gecachet wird, käme das aber nur beim ersten Mal vor.
Aber gut, das ist auch ein Argument, das erste Mal etwas komplizierter zu gestalten, da es ja eh nur einmal vorkommt ;-)

Auf EEXIST muß sowieso geprüft werden, da auch eine
PID im Laufe eines Serverlebens mehrfach (halt nur
nie gleichzeitig) auftauchen kann.

Kann sie - wirklich?

Ja.
Da ein rename() Fehler nicht abgefangen wird, kann die Datei weiterexistieren.
Wenn die PID Zählung am Ende angekommen ist, wird wieder am Anfang begonnen (nicht ganz und nur unter den mir bekannten Unices, aber das ist der Großteil der Server Betriebsysteme)
Das kann bei Großbetrieben durchaus häufiger auftauchen.

Aber ich gebe es zu: ist ein relativ schwaches Argument, wollte ja eigentlichg nur von getpid() weg ;-)

Die zlib erzeugt übrigens eine Checksum. Warum die nicht nehmen?
Nein, hast recht, würde die Sache unnötig verkomplizieren.

Mir ist immer noch nicht ganz eingängig, warum beim
Tempfile ein _ein_deutiger Identifikator da sein
muß.
Besser wäre es doch, in einem Temdir die Dateien mit
richtigem und vollständigem Namen abzulegen, sodaß
ein EEXIST die Mehrfachüberschreibung im Keime
erstickt.

Ich traue dem EEXIST nicht.
Ich traue überhaupt keinem trivialen Mechanismus zur
Synchronisation. Ein

if (! EEXIST)
      { create zipped file }

kann genau in dem Moment platzen, wenn nach dem "if"
ein Prozeßwechsel statt findet und der andere gzip-
Prozeß ebenfalls in die kritische Zone hinein läuft.

Das ist unwahrscheinlich, da diese Stelle linear ist.
Aber auch hier zugegeben: nur unwahrscheinlich, nicht unmöglich.

Da ist meine Hoffnung, daß dasselbe Problem innerhalb
des Betriebsystemkommandos für die Umbenennung einer
Datei zuverlässiger gelöst ist, als ich das könnte,
doch erheblich.

Gut, Dateisystembearbeitung wird im Normalfall in einem Rutsch abgearbeitet.
Zumindest in den mir bekannten Dateisystemen und Kerneln ;-)

Also komprimiert immer nur der erste gzip_cncc
Prozess die Datei und belastet den Prozessor und
das Dateisystem. Der Rest arbeitet ganz normal.

Der Fall der Kollision ist so selten, daß er in Sachen
CPU-Belastung irrelevant ist.
In Sachen Datenkonsistenz ist er es nicht, da die kom-
primierte Datei anschließend beliebig oft gelesen wer-
den könnte.

Da haut dann der Teil rein, daß Du unbedingt globale Indentifier haben wolltest. Wenn stattdessen die Identifier zur Datei gehörig wären, könnte man tatsächlich auf EEXIST gehen.
Aber bis jetzt ist Eure Version immer noch die einfachste.

Denke ich wirklich so kompliziert?
Scheint wohl so ;-)

Ich hatte eher den Umstand im Auge, das evt derselbe
Datei_name_ mehrfach in den Cache geschickt wird ;-)

Ich auch (falls derselbe Dateiname über entsprechende
Alias-Mappings auf mehrer URLs abgebildet wird, haben
wir halt ein bißchen Redundanz im Cache).

Ich meinte den umgekehrten Fall. Das also mehrere Dateien den gleichen Namen haben könnten. Ich kenne mich allerdings in den Pfadtranslationsmechanismen des Apachen nicht gut genug aus.
Die von Dir angesprocchen Redundanz ließe sich übrigens mit dem ZLib Checksum Mechanismus (ist zwar nur 32 Bit, aber das reicht ja in diesem Falle) vermeiden.
Aber ob sich der Aufwand lohnt?

Und ich wollte _eine_ Wurzel des Cache-Baums haben,
ohne dafür die Wurzel des gesamten Verzeichnisbaums zu
verwenden ... das wäre auch gegangen, hätte aber
längere Pfadnamen zur Folge gehabt.
Hätte auch keine große Rolle gespielt.

Es geht mir hier auch um die usability.
Ich selbst habe beim Testen immer wieder in den Cache
geschaut, um zu prüfen, ob alles so tut, wie es sollte.
Das wird den Benutzern, die gzip_cnc installieren,
möglicherweise ähnlich gehen - und in diesem Falle ist
ein "kurzer" Pfadname angenehm.

Ja, insbesondere für die Leute, die einem das automatisierte Runterladen schwer machen, in dem sie jede "Wurzeldatei" in jedem Unterverzeichnis als "index.html" bezeichnen.
*grrr*
;-)

die Trivial-Methode, nur fertige Dateien durch Umbe-
nennung um Cache "sichtbar" für andere Zugriffe zu
machen.
Na, _so_ trivial ist sie ja auch nicht ,-)

"rename" hat sich bei ähnlichen Fällen bewährt - ich
mache das seit vielen Jahren so. (Deshalb weiß ich
auch gar nicht, wie "flock" funktioniert ... ;-)

flock() ist ja auch immer so eine Sache und eh nicht ANSI ;-)
Bevor Du nachschaust: rename() ist:

C99: 7.19.4.2 The rename function
[...]
Among the reasons the implementation may cause the rename function to fail are that the file is open or that it is necessary to copy its contents to effectuate its renaming.

Oh!
Kommt davon, wenn man nicht nachschaut ,-)

Wollen hoffen das sich die jeweiligen Libc Implementationen auch an den Standard halten ;-)

so short

Christoph Zurnieden

PS: sind meine Mails angekommen?

[Michael Schröpl]

Hallo Christoph,

Da ein rename() Fehler nicht abgefangen wird, kann
die Datei weiterexistieren.
Wenn die PID Zählung am Ende angekommen ist, wird
wieder am Anfang begonnen (nicht ganz und nur unter
den mir bekannten Unices, aber das ist der Großteil
der Server Betriebsysteme)
Das kann bei Großbetrieben durchaus häufiger
auftauchen.

Aber wie lange dauert es zwischen zwei Prozeß-Instanzen
mit derselben PID? Länger, als das Gzippen einer Datei
dauert. Die übrig bleibende Cache-Datei tut nicht weh

• die wird beim nächsten Mal einfach überschrieben.

Es dürfen nur nicht _gleichzeitig_ zwei Prozesse mit
derselben PID laufen, weil die in dieselbe Datei
schreiben und ein korruptes Ergebnis erzeugen würden.

Die zlib erzeugt übrigens eine Checksum. Warum die
nicht nehmen?

Weil ich dann zuerst im Speicher komprimieren und
danach in die Datei schreiben müßte. Ich müßte also
die Daten lokal auch noch einmal puffern - und dazu
im schlimmsten Fall mit backticks die Ausgabe von
/bin/gzip -c auffangen, grusel ...

Ich hatte eher den Umstand im Auge, das evt
derselbe Datei_name_ mehrfach in den Cache
geschickt wird ;-)
Ich auch (falls derselbe Dateiname über ent-
sprechende Alias-Mappings auf mehrer URLs
abgebildet wird, haben wir halt ein bißchen
Redundanz im Cache).
Ich meinte den umgekehrten Fall. Das also mehrere
Dateien den gleichen Namen haben könnten.

Wie soll das gehen? Innerhalb eines Dateisystems, das
ich kenne, erscheint mir das unmöglich.

Ich kenne mich allerdings in den Pfadtranslations-
mechanismen des Apachen nicht gut genug aus.

Die Dokumentationen zu gzip_cnc und mod_gzip sind
beide zweisprachig und werden via Content Negotiation
über mehrdeutige URLs angesprochen - das ist wohl das
Szenario, welches Du meinst: Mehrdeutige Request-URLs.

gzip_cnc 1.04 wurde damit noch nicht fertig (und
gzip_cncc 0.2 meines Wissens auch nicht). gzip_cnc
1.05 dagegen macht das richtig (ich brauche es ja
für meine eigenen Seiten).

Es funktioniert so:

PATH_INFO ist der angeforderte URL _vor_ Negotiation;
PATH_TRANSLATION ist der vom Apache übersetzte Datei-
name _nach_ Negotiation. Dort sind beispielsweise auch
Directory-Zugriffe schon nach "index.html" etc über-
setzt - gzip_cnc bekommt immer einen eindeutigen
Dateinamen, allerdings nur in PATH_TRANSLATED, nicht
in PATH_INFO.

gzip_cnc 1.04 nahm noch komplett PATH_INFO und adres-
sierte dann in der Tat fälschlicherweise sämtliche
negotiated-Varianten eines URL über dieselbe Cache-
Datei, lieferte also zufällige und unbrauchbare Sprach-
Varianten aus (der erste Zugriff erzeugt die Cache-
Version, alle nachfolgenden Zugriffe glauben ihren
Inhalt).

gzip_cnc 1.05 nimmt, um nun den Pfadnamen der zuge-
hörigen Cache-Datei zu berechnen,
a) den Verzeichnispfad aus PATH_INFO, aber
b) den Dateinamen aus PATH_TRANSLATED.
Nun entstehen für index.htm.de und index.htm.en zwei
verschiedene Cache-Dateien, die beide für den URL
index.htm ausgeliefert werden könnten.

Ja, insbesondere für die Leute, die einem das
automatisierte Runterladen schwer machen, in dem
sie jede "Wurzeldatei" in jedem Unterverzeichnis
als "index.html" bezeichnen.
*grrr*
;-)

Wie meinen der Herr?

PS: sind meine Mails angekommen?

Äh ... hier privat nicht.
(Ins Büro komme ich erst wieder nach dem Halbfinale.)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christian Kruse]

Tag Michael, Tag Christoph,

gzip_cnc 1.04 wurde damit noch nicht fertig (und
gzip_cncc 0.2 meines Wissens auch nicht).

Doch, gzip_cncc wurde damit schon von Anfang an fertig. Ich
nehme (aus reiner Faulheit ;-) naemlich PATH_TRANSLATED als Basis.

PS: sind meine Mails angekommen?

Äh ... hier privat nicht.
(Ins Büro komme ich erst wieder nach dem Halbfinale.)

Bei mir schon (zwei Patches zu gzip_cncc). Aber ich bin noch nicht
dazu gekommen, die durchzuschauen -- irgendwie verlangt da wer meine
Zeit, gelle, Daniela? ;-)

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

gzip_cnc 1.04 wurde damit noch nicht fertig (und
gzip_cncc 0.2 meines Wissens auch nicht).

Doch, gzip_cncc wurde damit schon von Anfang an fertig. Ich
nehme (aus reiner Faulheit ;-) naemlich PATH_TRANSLATED als Basis.

Hey, ich wollte das gerade ausbauen!
Na, nun nicht mehr, wer derart meine Faulheit anspricht ...  ;-)))

PS: sind meine Mails angekommen?

Äh ... hier privat nicht.
(Ins Büro komme ich erst wieder nach dem Halbfinale.)

Bei mir schon (zwei Patches zu gzip_cncc).

Ein dritter ist in Arbeit.
Ich habe auch versucht den LCC zum kompilieren zu überreden, aber das ist unter wine eine ganz schöne Fummelei. Schlußendlich wollte der Linker auch nicht, den hatte ich dann überredet bekommen, so dachte ich zumindestens, aber die Ausführung brach dann mit einer ganz merkwürdigen Fehlermeldung ab. Muß mal den LCC bei kleiner Schwester installieren. Die hat noch Windows.
(Die ist noch paranoider als ich. Bevor die Win bootet zieht die immer den Modemstecker raus ;-)
Kann auch daran liegen, daß ich die vorgebauten Zlib-libs genommen habe. Ich hatte nun wirklich keine Lust, die auch noch zu bauen ;-)

Mußt also noch auf eine PE warten oder einen anderen Dummen finden.

Achso: kompilieren tut die jetzige Datei auch unter LCC ohne viel Warnungen (bei Warnlevel auf Maximum, gar keine bei normalem Warnlevel). Nichts bedeutendes dabei. (War eine ganz schöne Arbeit, ich kann Dir sagen! ;-)

Aber ich bin noch nicht
dazu gekommen, die durchzuschauen -- irgendwie verlangt da wer meine
Zeit, gelle, Daniela? ;-)

Jaja, ohne geht's nicht aber dafür mit schon mal gar nicht, oder? ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Tag,

Hey, ich wollte das gerade ausbauen!

Warum?

Na, nun nicht mehr, wer derart meine Faulheit anspricht ...  ;-)))

Naja, ich sehe ehrlich gesagt keine Probleme darin, PATH_TRANSLATED
anstelle von PATH_INFO zu nehmen.

Ich habe auch versucht den LCC zum kompilieren zu überreden,

LCC? Lint CC? Light CC? Oder wofuer steht das L?

(Die ist noch paranoider als ich. Bevor die Win bootet zieht die
immer den Modemstecker raus ;-)

Hoehoe ;-) Meine Schwester(n) tuen eher das Gegenteil. Ich hab schon
sieben oder acht Viren-Mails bekommen...

Achso: kompilieren tut die jetzige Datei auch unter LCC ohne
viel Warnungen (bei Warnlevel auf Maximum, gar keine bei normalem
Warnlevel). Nichts bedeutendes dabei. (War eine ganz schöne
Arbeit, ich kann Dir sagen! ;-)

Ich kenne den LCC nicht. Was ist an dem so besonders?

Aber ich bin noch nicht
dazu gekommen, die durchzuschauen -- irgendwie verlangt da wer
meine Zeit, gelle, Daniela? ;-)

Jaja, ohne geht's nicht aber dafür mit schon mal gar nicht,
oder? ;-)

Hm, ich sag lieber gar nix dazu, bevor ich was Falsches sage *g*

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Hey, ich wollte das gerade ausbauen!

Warum?

Purer Aktionismus? ;-)

Na, nun nicht mehr, wer derart meine Faulheit anspricht ...  ;-)))

Naja, ich sehe ehrlich gesagt keine Probleme darin, PATH_TRANSLATED
anstelle von PATH_INFO zu nehmen.

Probleme nicht, aber der Cachebaum sähe dann aber genauso aus, wie die ursprüngliche Perlvariante.

Gut, ich gebe es zu: reine Geschmackssache ;-)

Ich habe auch versucht den LCC zum kompilieren zu überreden,

LCC? Lint CC? Light CC? Oder wofuer steht das L?

Och, frag mich doch nicht so etwas schweres! ;-)

Bin übrigens gerade wieder dabei. Habe mir jetzt die gesammten Quellen und Patches und Buildinstructins für dei Windows ZLibversion geholt. Mal schauen.

(Die ist noch paranoider als ich. Bevor die Win bootet zieht die
immer den Modemstecker raus ;-)

Hoehoe ;-) Meine Schwester(n) tuen eher das Gegenteil. Ich hab schon
sieben oder acht Viren-Mails bekommen...

War auch eine verdammt mühsame Überzeugungsarbeit, ich kann Dir sagen.
Manch ein Politiker hat mit bedeutend weniger einen Wahlkampf gewonnen! ;-)

Achso: kompilieren tut die jetzige Datei auch unter LCC ohne
viel Warnungen (bei Warnlevel auf Maximum, gar keine bei normalem
Warnlevel). Nichts bedeutendes dabei. (War eine ganz schöne
Arbeit, ich kann Dir sagen! ;-)

Ich kenne den LCC nicht. Was ist an dem so besonders?

Ist ein optimierender C-Compiler mit allem Drum und Dran, kost' nix und für 20US$ extra gibts sogar noch die Quellen dazu.

Ist der Windowsport des ursprünglichen LCC (von anno Dunnemals. War noch lange vor dem GCC)

Aber ich bin noch nicht
dazu gekommen, die durchzuschauen -- irgendwie verlangt da wer
meine Zeit, gelle, Daniela? ;-)

Jaja, ohne geht's nicht aber dafür mit schon mal gar nicht,
oder? ;-)

Hm, ich sag lieber gar nix dazu, bevor ich was Falsches sage *g*

Feind liest mit, ha? ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Tag,

Purer Aktionismus? ;-)

Tss, leite deine ueberschuessigen Energien doch dahin, wo es
sinnvoll ist ;-))

Och, frag mich doch nicht so etwas schweres! ;-)

Doch! ;-)

Bin übrigens gerade wieder dabei. Habe mir jetzt die gesammten
Quellen und Patches und Buildinstructins für dei Windows
ZLibversion geholt. Mal schauen.

Sollt ich vielleicht auch mal machen. Ich habe hier ja sogar ein
Win-System ;-))

War auch eine verdammt mühsame Überzeugungsarbeit, ich kann Dir
sagen.

Das glaub ich dir aufs Wort ;-))

Manch ein Politiker hat mit bedeutend weniger einen Wahlkampf
gewonnen! ;-)

Braucht man viel, um einen Wahlkampf zu gewinnen? Ich dachte, da muss
man seinen 'Gegner' nur solange mit Schlamm bewerfen, bis die Wahl
um ist? ;-))

Ist ein optimierender C-Compiler mit allem Drum und Dran, kost'
nix und für 20US$ extra gibts sogar noch die Quellen dazu.

Aha.

Hm, ich sag lieber gar nix dazu, bevor ich was Falsches sage *g*

Feind liest mit, ha? ;-)

So weit unten ists unwahrscheinlich, aber wer weiss? Vorsicht ist die
Mutter der Porzellankiste ;-))

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Entschuldige bitte die Verspätung, aber der Konqueror 2.2.2 hat wohl Schwierigkeiten beim Refresh, zeigt nicht alles an hier im Thread.
Oder liegt's am Forum?
Hatte vorher eigentlich noch nie Probleme.

Purer Aktionismus? ;-)

Tss, leite deine ueberschuessigen Energien doch dahin, wo es
sinnvoll ist ;-))

Da bereitet es aber seltenst Freude! ;-)

Bin übrigens gerade wieder dabei. Habe mir jetzt die gesammten
Quellen und Patches und Buildinstructins für dei Windows
ZLibversion geholt. Mal schauen.

Sollt ich vielleicht auch mal machen. Ich habe hier ja sogar ein
Win-System ;-))

Wie gesagt, geholt hab' ich sie ... ;-)

Manch ein Politiker hat mit bedeutend weniger einen Wahlkampf
gewonnen! ;-)

Braucht man viel, um einen Wahlkampf zu gewinnen? Ich dachte, da muss
man seinen 'Gegner' nur solange mit Schlamm bewerfen, bis die Wahl
um ist? ;-))

Ja, genau >;->

Ist ein optimierender C-Compiler mit allem Drum und Dran, kost'
nix und für 20US$ extra gibts sogar noch die Quellen dazu.

Aha.

Ich habe ihn jetzt auch unter Windows betrachten dürfen, da gibts dann eine GUI, die unter Wine nicht funktierte (Was mir sowas von völlig egal ist ;-).

Ziemlich viel Clickibunti(TM), aber noch meilenweit entfernt von dem Visual Crap o.ä.

So,habe Dir gerade einen Tarball mit Autoconf und allem geschickt.
Wenn Du Dich selber unter Windows versuchen möchtest: ich habe alle nötigen defines gesetzt. Da gibt es schonmal keine Probleme. (Zumindest bei der Benutzung von LCC nicht ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Hallo Christoph,

Entschuldige bitte die Verspätung,

Nein!
;-)

aber der Konqueror 2.2.2 hat wohl Schwierigkeiten beim Refresh, zeigt nicht
alles an hier im Thread.

Vielleicht der Expires:-Header?

Oder liegt's am Forum?

Nein. Ich hab keine Probleme.

So,habe Dir gerade einen Tarball mit Autoconf und allem geschickt.

Danke.
Aber ich werde nicht dazu kommen, bis zu meinem Urlaub. Tut mir leid.

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Entschuldige bitte die Verspätung,

Nein!
;-)

Ja, ich gebe es zu, Du hast recht: es war eine Floskel ;-)

aber der Konqueror 2.2.2 hat wohl Schwierigkeiten beim Refresh, zeigt nicht
alles an hier im Thread.

Vielleicht der Expires:-Header?

Jetzt habe ich ihn mal neu gestartet, jetzt scheint es zu funktionieren.
Also ich weiß ja nicht.
KDE wird Windows immer ähnlicher ;-)

Oder liegt's am Forum?

Nein. Ich hab keine Probleme.

Das Du keine Probleme hast ist aber kein Beweis! ;-)

So,habe Dir gerade einen Tarball mit Autoconf und allem geschickt.

Danke.
Aber ich werde nicht dazu kommen, bis zu meinem Urlaub. Tut mir leid.

Macht nichts.
Wenn Du nur die Lizenz für gzip_cncc klarstellen würdest.
Ja, ich kann es mir schon denken, ich brauche es nur juristisch eindeutig ;-)

Ist es diese hier?
http://www.statistica.unimib.it/utenti/dellavedova/software/artistic2.html

Fände es nett, wenn Du das vor Deinem wohlverdientem (? ;-) Urlaub noch tuen könntest.

so short

Christoph Zurnieden

[Christian Kruse]

Moin,

Also ich weiß ja nicht.
KDE wird Windows immer ähnlicher ;-)

Hoehoe. Sieht so aus als koenne das Ausprobieren von KDE3 noch etwas
warten?

Das Du keine Probleme hast ist aber kein Beweis! ;-)

Willst du etwa behaupten, ich luege?! ;-)

Wenn Du nur die Lizenz für gzip_cncc klarstellen würdest.

Artistic ;-)

Ja, ich kann es mir schon denken, ich brauche es nur juristisch
eindeutig ;-)

Ist es diese hier?
http://www.statistica.unimib.it/utenti/dellavedova/software/artistic2.html

Jau.

Fände es nett, wenn Du das vor Deinem wohlverdientem (? ;-)
Urlaub noch tuen könntest.

Ich versuchs ;-)

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Also ich weiß ja nicht.
KDE wird Windows immer ähnlicher ;-)

Hoehoe. Sieht so aus als koenne das Ausprobieren von KDE3 noch etwas
warten?

Naja, über 'startx -- :0' kann ich auf einer anderen Konsole immer noch FVWM2 starten, zwecks Entspannung ;-)

Jaja, habe ich neulich gehört, daß es unter WindowsXP jetzt ein "fast user switching" gibt. Hier wäre sowas im obigem Falle STRG+ALT+F8 ;-)

Das Du keine Probleme hast ist aber kein Beweis! ;-)

Willst du etwa behaupten, ich luege?! ;-)

Nein, keineswegs. Warum solltest Du?
Nur weil Du den Server gebastelt hast? ;-)

Ja, ich kann es mir schon denken, ich brauche es nur juristisch
eindeutig ;-)

Ist es diese hier?
http://www.statistica.unimib.it/utenti/dellavedova/software/artistic2.html

Jau.

Gut, dann brauche ich die Pakete wenigstens nicht mehr zu verschicken.
War mir doch etwas unangenehm.

Ist dann ab heute Abend (nein, besser ab morgen ;-) unter
http://mzurnieden.bei.t-online.de/download.html
zu bekommen.

Auch hier wieder: besten Dank an kleines Schwesterschwei^H^H^H^lein für die Verfügungstellung ihres Platzes bei T-Offline.

Fände es nett, wenn Du das vor Deinem wohlverdientem (? ;-)
Urlaub noch tuen könntest.

Dann bedanke ich mich recht herzlich und wünsche einen entspannenden Urlaub!

so short

Christoph Zurnieden

[Christian Kruse]

Tag,

Gut, dann brauche ich die Pakete wenigstens nicht mehr zu
verschicken.
War mir doch etwas unangenehm.

Warum?

Ist dann ab heute Abend (nein, besser ab morgen ;-) unter
http://mzurnieden.bei.t-online.de/download.html
zu bekommen.

Ehrlich gesagt waere es mir lieber, wenn gzip_cncc von einem
zentralen Ort aus verteilt wird, und es nicht x Stellen gibt, wo es
x verschiedene Versionen gibt.

Fände es nett, wenn Du das vor Deinem wohlverdientem (? ;-)
Urlaub noch tuen könntest.

Dann bedanke ich mich recht herzlich und wünsche einen
entspannenden Urlaub!

Das dauert noch ein wenig ;-) Ich kriege erst am 15. nexten Monats
Urlaub. Leider. Dafuer aber dann gleich drei Wochen *g*

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Gut, dann brauche ich die Pakete wenigstens nicht mehr zu
verschicken.
War mir doch etwas unangenehm.

Warum?

Ich habe einen recht hohen Ausstoß an Versionen.
Habe mich beim Verschicken schon arg zurückhalten müssen.
Dieses "zurückhalten müssen" war mir unangenehm ;-)

Ist dann ab heute Abend (nein, besser ab morgen ;-) unter
http://mzurnieden.bei.t-online.de/download.html
zu bekommen.

Ehrlich gesagt waere es mir lieber, wenn gzip_cncc von einem
zentralen Ort aus verteilt wird, und es nicht x Stellen gibt, wo es
x verschiedene Versionen gibt.

Möchtest Du die Lizenz wieder zurückziehen?
Bleibt Dir selbstverständlch unbenommen.

Dann ziehe ich aber wahrscheinlich meinen Code auch wieder zurück. (Je nach neuer Lizenz natürlich nur! Ich bin nicht eingeschnappt, möchte nur den von mir geschrieben Code auf jeden Fall öffentlich zugänglich und frei benutzbar halten. Ich schmeiß ihn wirklich lieber weg, als in propietärem Code aufzutauchen)

Muß übrigens nicht unbedingt "OSI approved" sein, so streng bin ich dann auch wieder nicht ;-)

Fände es nett, wenn Du das vor Deinem wohlverdientem (? ;-)
Urlaub noch tuen könntest.

Dann bedanke ich mich recht herzlich und wünsche einen
entspannenden Urlaub!

Das dauert noch ein wenig ;-) Ich kriege erst am 15. nexten Monats
Urlaub. Leider. Dafuer aber dann gleich drei Wochen *g*

In den Sommerferien?
Glück oder Bestechung? ;-)

OT:
Vielleicht hast Du dann ja Zeit und Lust bei http://www.ssgrr.it/en/ssgrr2002s/index.htm vorbeizuschauen. Recht illustres Publikum.
Eigentlich sollte ich da ja auch einen Vortrag halten, aber ich konnte mich noch rechtzeitig drücken ;-) (Ich hatte die mathematischen Grundlagen zum Rechtesystem von http://www.askemos.org in Formeln, Worte und Latex gefaßt. Mußte dabei feststellen, daß es doch verdammt lang her war mit der Mengenlehre ;-)

TOT:
BTW: kennt sich jemand aus, oder kennt jemand jemanden, der sich auskennt und zwar mit Statistik? Ich kenne nur einen Versicherungsmathematiker und der ist in Urlaub und wie immer ist es dringend ;-)
Geht um Fehlerwahrscheinlichkeit in komplexen Systemen mit n->oo Einzelknoten (wobei n im Laufe der Zeit gegen 0 geht) und zwar da um die Summe aller, also um die Fehlerwahrscheinlichkeit des ganzen Systems im linearem Bezug zur Zeit.

so short

Christoph Zurnieden

PS: um Dir doch noch den Mund wässerig zu machen:
Das Paket ist inkl Autoconf soweit fertig.
Fehlt noch versäubern, extensives Testen und evt Bugfixing (Wieso überhaupt evt? ;-)

[Christian Kruse]

Tag,

Ich habe einen recht hohen Ausstoß an Versionen.

Hoehoe. Geht mir aehnlich ;-)

Habe mich beim Verschicken schon arg zurückhalten müssen.
Dieses "zurückhalten müssen" war mir unangenehm ;-)

Dann lass es halt?

Ist dann ab heute Abend (nein, besser ab morgen ;-) unter
http://mzurnieden.bei.t-online.de/download.html
zu bekommen.

Ehrlich gesagt waere es mir lieber, wenn gzip_cncc von einem
zentralen Ort aus verteilt wird, und es nicht x Stellen gibt, wo es
x verschiedene Versionen gibt.

Möchtest Du die Lizenz wieder zurückziehen?

Nee. Ich denke, da kann man sich auch so einigen ;-)

Dann ziehe ich aber wahrscheinlich meinen Code auch wieder zurück. (Je nach
neuer Lizenz natürlich nur! Ich bin nicht eingeschnappt, möchte nur den von
mir geschrieben Code auf jeden Fall öffentlich zugänglich und frei benutzbar
halten. Ich schmeiß ihn wirklich lieber weg, als in propietärem Code
aufzutauchen)

Oh, mir geht es nicht darum, den Code nicht oeffentlich und unverfuegbar zu
machen ;-) Ich bin ueberzeugter Open-Sourceler. Ich faends nur schade, wenn es
auf zig Domains zig unterschiedliche Versionen gaebe. Warum nicht eine zentrale
Version?

In den Sommerferien?

jau ;-))

Glück oder Bestechung? ;-)

Hehe. Weder noch ;-) Chef hat mich gefragt, ich hab Zeitraum genannt, er hat
ok gesagt *g*

OT:
Vielleicht hast Du dann ja Zeit und Lust bei http://www.ssgrr.it/en/ssgrr2002s/index.htm vorbeizuschauen.
Recht illustres Publikum.

Das ist mir ein wenig zu teuer... 600 Euro, die hab ich nicht. Die verdien
ich gerade mal in einem Monat ;-)

PS: um Dir doch noch den Mund wässerig zu machen:
Das Paket ist inkl Autoconf soweit fertig.
Fehlt noch versäubern, extensives Testen und evt Bugfixing (Wieso überhaupt
evt? ;-)

Schicks mir mal zu, ja? Ich sehe, ob ich das morgen noch durchtesten kann. Ich
kann aber nix versprechen.

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Ich habe einen recht hohen Ausstoß an Versionen.

Hoehoe. Geht mir aehnlich ;-)

Oh ja, immer wenn ich ein Paket rausgegeben habe, fällt mir siedendheiß ein Fehler ein. Und zügig gibt's 'ne neue Version ;-)

Habe mich beim Verschicken schon arg zurückhalten müssen.
Dieses "zurückhalten müssen" war mir unangenehm ;-)

Dann lass es halt?

Das Verschicken oder die Zurückhaltung? ;-)

Dann ziehe ich aber wahrscheinlich meinen Code auch wieder zurück. (Je nach
neuer Lizenz natürlich nur! Ich bin nicht eingeschnappt, möchte nur den von
mir geschrieben Code auf jeden Fall öffentlich zugänglich und frei benutzbar
halten. Ich schmeiß ihn wirklich lieber weg, als in propietärem Code
aufzutauchen)

Oh, mir geht es nicht darum, den Code nicht oeffentlich und unverfuegbar zu
machen ;-) Ich bin ueberzeugter Open-Sourceler. Ich faends nur schade, wenn es
auf zig Domains zig unterschiedliche Versionen gaebe. Warum nicht eine zentrale
Version?

Meinetwegen.

CVS? (Ich hasse CVS! Gibt es denn nichts besseres?)
Sourceforge (Ungern. Wird in letzter Zeit immer nerviger)

Also nenne mir einen guten Grund, warum ich nicht einfach (Aber selbstverständlich streng nach den Spielregeln!) forken soll? ;-)

OT:
Vielleicht hast Du dann ja Zeit und Lust bei http://www.ssgrr.it/en/ssgrr2002s/index.htm vorbeizuschauen.
Recht illustres Publikum.

Das ist mir ein wenig zu teuer... 600 Euro, die hab ich nicht. Die verdien
ich gerade mal in einem Monat ;-)

Ja, es ist ein wenig exclusiv (mit "c"! ;-) aber schön gelegen! ;-)

Den Rest schamvoll gelöscht?
Jaja, alle ignorieren mich *sniff* ;-)

PS: um Dir doch noch den Mund wässerig zu machen:
Das Paket ist inkl Autoconf soweit fertig.
Fehlt noch versäubern, extensives Testen und evt Bugfixing (Wieso überhaupt
evt? ;-)

Schicks mir mal zu, ja? Ich sehe, ob ich das morgen noch durchtesten kann. Ich
kann aber nix versprechen.

Reiß Dir nichts auf, was nicht eh schon gespalten ist ;-)

Gut, ich schau nochmal schnell durch. 'make distclean' und weg damit.
Jetzt habe ich doch noch ein paar Dinge geändert. Hoffentlich funktionierts noch.
Das ich auch nie endgültig die Finger davon lassen kann ... ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Christoph,

Also nenne mir einen guten Grund, warum ich nicht
einfach (Aber selbstverständlich streng nach den
Spielregeln!) forken soll? ;-)

es verwirrt die Anwender.

Und ob solche spin-offs dann noch guten Gewissens auf
meine gzip_cnc-Seiten linken könnten oder lieber doch
eine eigene Dokumentation schreiben müßten (viel Spaß
dabei!), das ist auch noch eine Frage.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Also nenne mir einen guten Grund, warum ich nicht
einfach (Aber selbstverständlich streng nach den
Spielregeln!) forken soll? ;-)

es verwirrt die Anwender.

Du hast das Grinsemännchen gesehen, ja?

Aber dann laß mich doch mal mein Beckmesser aus der Scheide ziehen:

Wäre es wirklich ein Fork?
Ja, aber höchsten eine "Entwicklerversion", ähnlich den Produkten von Allan Cox et al., aber: ja, ganz streng genommen wäre es ein Fork.

Halte ich mich an die Spielregeln?
Da ich noch nichts veröffentlicht habe, kann ich nur sagen, wie ich es machen würde und müßte:
Alle Änderungen kennzeichnen (Wie ich das im Code und im Paketnamen schon gemacht habe, nur das Binary fehlt noch), bzw das Original zur Verfügung stellen (wie ich das im Falle des READMEs getan habe)

Würde ich das durchziehen?
Neee, warum sollte ich? ;-)

Und ob solche spin-offs dann noch guten Gewissens auf
meine gzip_cnc-Seiten linken könnten

Ich bin mir nicht 100%ig sicher, aber ich glaube sie _müßten_ sogar.

oder lieber doch
eine eigene Dokumentation schreiben müßten (viel Spaß
dabei!)

Warum?
Deine Dokumentation steht mit unter der Artistic License, die könnte ich einfach übernehmen. Nur Deinen Namen drübersetzen, alle meine Änderungen markieren und fertig.

das ist auch noch eine Frage.

Nein, die stellt sich nicht. Einmal aus der Lizenz heraus und zum zweiten will ich auch gar nicht forken. Ich wollte nur das Ergebnis meiner Arbeit veröffentlichen, damit auch andere Leute, als nur wir drei davon profitieren können.
Und sei es nur als "How to not do" ;-)

Was ich in meiner Freizeit an Code schreibe ist prinzipiell Open Source.

Ansonsten sind 69,20EUR/Std + MwSt fällig, dann darfst Du ihn auch behalten und tun und lassen damit, wie es Dir beliebt ;-)

BTW: Ich hielt die 69,20 eigentlich immer für prohibitiv genug, um als Scherz erkannt werden zu können, aber da gab es doch letzte Tage mal eine Diskussion hier, was denn so ein Programmierer (IMHO: PHP, MySQL) verdienen sollte und es kamen so Summen von 45EUR/Std und mehr auf's Tapet. Für einen PHP Programmierer mit ein wenig SQL?
Na, ich weiß ja nicht. Wenn man mir garantiert, daß immer genügend frischer Kaffe da ist und ab und zu mal eine warme Mahlzeit, würde ich das glatt für die Hälfte machen.
Auch auf die Gefahr hin, daß man mich des Preisdumpings beschuldigen würde ;-)

so short

Christoph Zurnieden, der ein wenig irritiert darüber ist, das er derart angepflaumt wurde, nur weil er darauf besteht, daß sein Code frei und erhältlich bleiben soll.

[Christian Kruse]

Tag,

Du hast das Grinsemännchen gesehen, ja?

Jetzt mal immer mit die Ruhe.

Würde ich das durchziehen?
Neee, warum sollte ich? ;-)

Weiss nicht ;-) Hoerte sich so an.

das ist auch noch eine Frage.

Nein, die stellt sich nicht. Einmal aus der Lizenz heraus und zum
zweiten will ich auch gar nicht forken. Ich wollte nur das
Ergebnis meiner Arbeit veröffentlichen, damit auch andere Leute,
als nur wir drei davon profitieren können.

Na, wer sagt denn, dass deine Aenderungen nicht eingearbeitet werden?
Da waer ich ja schoen bloed. Warum sollte ich mir Arbeit doppelt
machen?
Das einzige, was ich etwas seltsam gefunden haette, waeren n
Versionen auf n Servern (wobei n > 1). Das verwirrt einfach.

Und sei es nur als "How to not do" ;-)

Was ich in meiner Freizeit an Code schreibe ist prinzipiell Open
Source.

Dito.
Dem hat ja auch keiner Widersprochen. Ging ja nur darum, dass es
nicht irgendwelche Ableger gibt, sondern einen Entwicklungs-Zweig.
Damit man das ganze einfach beieinander hat. Und verboten hats dir
ja auch keiner. Wenn du Lust dazu hast -- bitte sehr. Ist einfach
IMHO nicht sonderlich sinnvoll, es traegt nicht gerade zur
Verbreitung von gzip_cnc[c] bei.

Christoph Zurnieden, der ein wenig irritiert darüber ist, das er
derart angepflaumt wurde, nur weil er darauf besteht, daß sein
Code frei und erhältlich bleiben soll.

Wer hat dich denn angepflaumt? ;-)

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Du hast das Grinsemännchen gesehen, ja?

Jetzt mal immer mit die Ruhe.

Da habe ich wohl vor Aufgeregtheit ein Grinsemännchen vergessen, was? ;-)

Würde ich das durchziehen?
Neee, warum sollte ich? ;-)

Weiss nicht ;-) Hoerte sich so an.

Dann bitte ich um Entschuldigung.
Der Eindruck sollte wirklich nicht entstehen.

das ist auch noch eine Frage.

Nein, die stellt sich nicht. Einmal aus der Lizenz heraus und zum
zweiten will ich auch gar nicht forken. Ich wollte nur das
Ergebnis meiner Arbeit veröffentlichen, damit auch andere Leute,
als nur wir drei davon profitieren können.

Na, wer sagt denn, dass deine Aenderungen nicht eingearbeitet werden?
Da waer ich ja schoen bloed. Warum sollte ich mir Arbeit doppelt
machen?

Dann entscheidest Du aber alleine, was reinkommt. Ist ja auch Dein gutes Recht und wer bin ich, dieses Recht auch nur in Frage zu stellen.

Aber der Rest landet dann im Orkus. Kein anderer außer uns dreien kennt den Inhalt. Vielleicht können andere davon auch etwas gebrauchen? Für etwas ganz anderes meinetwegen?

Wie oft sind wir schon durch anderer Leute Code gegangen und haben mit dem Ausruf:"Ach, so geht das!" die eine oder andere Zeile/Konstrukt daraus entnommen?

Das einzige, was ich etwas seltsam gefunden haette, waeren n
Versionen auf n Servern (wobei n > 1). Das verwirrt einfach.

Und da schrieb ich extra oben an: OT (Out of Thread) bzw TOT (Terribly Out of Thread)! *sigh* ;-)

Und sei es nur als "How to not do" ;-)

Was ich in meiner Freizeit an Code schreibe ist prinzipiell Open
Source.

Dito.
Dem hat ja auch keiner Widersprochen. Ging ja nur darum, dass es
nicht irgendwelche Ableger gibt, sondern einen Entwicklungs-Zweig.
Damit man das ganze einfach beieinander hat.

Gut, wenn der Zaunpfahl übersehen wird, dann muß hier mal der 220kV Überlandmast her zum winken ;-)

Was ist mit Mailingliste? CVS? Irgendwas in der Art?
Gibt es alles umsonst und kost' nur die Mühe.

Und verboten hats dir
ja auch keiner. Wenn du Lust dazu hast -- bitte sehr.

Nein, mit Sicherheit nicht. Dazu habe ich keine Zeit.

Ist einfach
IMHO nicht sonderlich sinnvoll, es traegt nicht gerade zur
Verbreitung von gzip_cnc[c] bei.

An der ich auch durchaus interessiert bin. Ich habe schließlich immer noch ein Modem (Sch.. Quälekom! Immer noch kein DSL!) mit Dialup und zahle pro Minute.

Christoph Zurnieden, der ein wenig irritiert darüber ist, das er
derart angepflaumt wurde, nur weil er darauf besteht, daß sein
Code frei und erhältlich bleiben soll.

Wer hat dich denn angepflaumt? ;-)

Weiß ich nicht mehr. Möchte jetzt auch meine durchschnittliche Nachtragszeit von ca 3 Sek deswegen nicht erhöhen ;-)

so short

Christoph Zurnieden

[Chritsian Kruse]

Tag Christoph,

Da habe ich wohl vor Aufgeregtheit ein Grinsemännchen vergessen, was? ;-)

Offensichtlich ;-) Was so ein Ding alles ausmacht *g*

Dann bitte ich um Entschuldigung.

Was gibts da zu entschuldigen?

Dann entscheidest Du aber alleine, was reinkommt.

Iwo. Das entscheide ich doch nicht.

Ist ja auch Dein gutes Recht und wer bin ich, dieses Recht auch nur in
Frage zu stellen.

Jemand, der viel Arbeit da 'rein gesteckt hat.

Wie oft sind wir schon durch anderer Leute Code gegangen und haben mit dem
Ausruf:"Ach, so geht das!" die eine oder andere Zeile/Konstrukt daraus
entnommen?

Oefter :)

Gut, wenn der Zaunpfahl übersehen wird, dann muß hier mal der 220kV
Überlandmast her zum winken ;-)

Was ist mit Mailingliste? CVS? Irgendwas in der Art?
Gibt es alles umsonst und kost' nur die Mühe.

Ja, aber meinst du nicht, das ist etwas uebertrieben fuer so ein kleines
Projekt?

Nein, mit Sicherheit nicht. Dazu habe ich keine Zeit.

*g*

An der ich auch durchaus interessiert bin. Ich habe schließlich immer noch
ein Modem (Sch.. Quälekom! Immer noch kein DSL!) mit Dialup und zahle pro
Minute.

Ja, dito :)

Weiß ich nicht mehr. Möchte jetzt auch meine durchschnittliche
Nachtragszeit von ca 3 Sek deswegen nicht erhöhen ;-)

*denk*
Was hast du gesagt?
;-)

Gruesse,
 CK, back from weekend :(

[Christoph Zurnieden]

Hallo,

(Mensch, schreib doch mal Deinen Namen richtig, sonst find ich Dich in diesem Riesenthread nur durch Zufall wieder ;-)

Ist ja auch Dein gutes Recht und wer bin ich, dieses Recht auch nur in
Frage zu stellen.

Jemand, der viel Arbeit da 'rein gesteckt hat.

Nunja, soooo viel war das auch nicht.
Aber sag' das bloß nicht weiter! ;-)

Gut, wenn der Zaunpfahl übersehen wird, dann muß hier mal der 220kV
Überlandmast her zum winken ;-)

Was ist mit Mailingliste? CVS? Irgendwas in der Art?
Gibt es alles umsonst und kost' nur die Mühe.

Ja, aber meinst du nicht, das ist etwas uebertrieben fuer so ein kleines
Projekt?

Warum?
Da sind andere schon mit weniger angekommen. ;-)

Neee Du, das ist eine _zu_ billige Entschuldigung.

An der ich auch durchaus interessiert bin. Ich habe schließlich immer noch
ein Modem (Sch.. Quälekom! Immer noch kein DSL!) mit Dialup und zahle pro
Minute.

Ja, dito :)

Da grinst er.
Mir ist das Grinsen bei dem Thema schon lange vergangen.
Sieht wohl nicht so aus, als ob DSL hier jemals hinkommen würde. Ist hier weder am Arsch der Welt, noch sonstwas. Liegen halt nur ein paar hundert Meter zu weit vom nächsten Knotenpunkt entfernt.
Tja und SkyDSL ist ja wohl auch was für'n ... , na, sag ich lieber nicht ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Christoph,

Wenn Du nur die Lizenz für gzip_cncc klarstellen würdest.
Ja, ich kann es mir schon denken, ich brauche es nur juristisch eindeutig ;-)
Ist es diese hier?
http://www.statistica.unimib.it/utenti/dellavedova/software/artistic2.html

ich beobachte diese Diskussion mit Interesse, weil ich
an dieser Stelle selbst reichlich unsicher bin.

gzip_cnc sollte auf jeden Fall Open Source sein, und
eine Lizenz bekommen, die möglichst wenig verbietet.
Insofern habe ich mir die Artistic License empfehlen
lassen ... ich habe dann versucht, sie selbst nach
Deutsch zu übersetzen, diesen Versuch dann aber wieder
abgebrochen, weil ich beim gründlichen Lesen mehr und
mehr den Eindruck bekam, daß diese Lizenz eigentlich
die Anforderungen eines Perl-Skripts überhaupt nicht
treffend beschreibt.
Etwas Besseres weiß ich aber auch nicht ... und selbst
etwas zu verzapfen, was juristisch bestenfalls ein
Blindflug sein könnte, wollte ich dann auch nicht.

Also habe ich letzten Endes einen Link auf eine mir
möglichst offiziell erscheinende Quelle der Artistic
License eingebaut ... und hoffe, daß das so halbwegs
taugt.
Für allfällige Tips bezüglich einer besseren Absiche-
rung dieser Situation wäre ich durchaus dankbar ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Wenn Du nur die Lizenz für gzip_cncc klarstellen würdest.
Ja, ich kann es mir schon denken, ich brauche es nur juristisch eindeutig ;-)
Ist es diese hier?
http://www.statistica.unimib.it/utenti/dellavedova/software/artistic2.html

ich beobachte diese Diskussion mit Interesse, weil ich
an dieser Stelle selbst reichlich unsicher bin.

gzip_cnc sollte auf jeden Fall Open Source sein, und
eine Lizenz bekommen, die möglichst wenig verbietet.

Und was hat Dir an der GPL nicht gepaßt?
Nein, ernsthafte Frage. Wie soll man sonst ergründen, welche der Lizenzen Dir evt besser zu Gesichte steht?

Also habe ich letzten Endes einen Link auf eine mir
möglichst offiziell erscheinende Quelle der Artistic
License eingebaut ... und hoffe, daß das so halbwegs
taugt.

Muß eigentlich mit in's Paket rein.
(Ist ja nicht so groß)

Für allfällige Tips bezüglich einer besseren Absiche-
rung dieser Situation wäre ich durchaus dankbar ...

Bei eigenständigen Programmen ist die GPL selten verkehrt.
Müssen aber wirklich eigenständig sein!

Deshalb ist der Einbau der ZLib schon schwierig.
BTW: die ZLib Lizenz ist auch nicht ohne! Wie wäre es mit der?

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Christian,

Und was hat Dir an der GPL nicht gepaßt?

ich habe nicht versucht, beliebig viele Lizenzen zu
verstehen oder gar miteinander zu vergleichen.
Die juristischen Spitzfindigkeiten will ich gar nicht
wirklich verstehen müssen.

Also habe ich letzten Endes einen Link auf eine mir
möglichst offiziell erscheinende Quelle der Artistic
License eingebaut ... und hoffe, daß das so halbwegs
taugt.
Muß eigentlich mit in's Paket rein.
(Ist ja nicht so groß)

Gute Idee, wird gemacht.

Reicht das als separate Datei, oder muß es in den Quelltext des Perl-Skripts rein (wie bei mod_gzip)?

Bei eigenständigen Programmen ist die GPL selten verkehrt.
Müssen aber wirklich eigenständig sein!

Was bedeutet "eigenständig"? gzip_cnc benutzt ein
Komprimierungsverfahren, das nicht von ihm ist ...
ich weiß jedoch nicht mal, welches, weil ich mehrere
ausprobiere und nehme, was ich kriegen kann ... ich
rufe diese Komprimierungsprogramme aber nur auf, habe
nichts von ihnen in mein Programm eingebaut (anders
als die zlib bei den binary downloads von gzip_cncc,
wo sie ja wohl mit rein gelinkt sein muß - oder?).

BTW: die ZLib Lizenz ist auch nicht ohne! Wie wäre es mit der?

Für welche(s) der beiden gzip_cnc*-Produkte?

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Hallo Christian,

Mmh..., was mach ich jetzt?
Typo vermuten und einfach und, eingebildet und von mir in höchstem Maße selbst eingenommen, wie ich nun mal bin, auf mich selbst beziehen? ;-)

Und was hat Dir an der GPL nicht gepaßt?

ich habe nicht versucht, beliebig viele Lizenzen zu
verstehen oder gar miteinander zu vergleichen.
Die juristischen Spitzfindigkeiten will ich gar nicht
wirklich verstehen müssen.

Versuch es gar nicht erst. Soviel Aspirin, wie man da braucht, kann Bayer gar nicht so schnell produzieren >;->

Also habe ich letzten Endes einen Link auf eine mir
möglichst offiziell erscheinende Quelle der Artistic
License eingebaut ... und hoffe, daß das so halbwegs
taugt.
Muß eigentlich mit in's Paket rein.
(Ist ja nicht so groß)

Gute Idee, wird gemacht.

Reicht das als separate Datei, oder muß es in den Quelltext des Perl-Skripts rein (wie bei mod_gzip)?

Üblich ist es, sie als Datei 'LICENCE' mit in's Paket zu packen. Nur wenn es eine einzelne Datei ist, muß sie in den Kopf. Dann reicht aber auch der übliche Hinweis. Und ich hätte Dir gerne mal einen hier hin C&P'd, aber jetzt finde ich natürlich auf die Schnelle nichts ;-)
Ist irgendwas in der Richtung: "Es gelten die Bestimmungen der GPL Version 2 oder, nach Belieben einer späteren Version. Alle Haftung ausgeschlossen" usw.

Bei eigenständigen Programmen ist die GPL selten verkehrt.
Müssen aber wirklich eigenständig sein!

Was bedeutet "eigenständig"?

Ja, das ist wirklich manchmal eine gute Frage.
Irgendwo drauf sitzt das Programm am Ende ja immer.
Bei einer Bibliothek ist das noch haariger. Aus dem Grunde wurde auch die LGPL rausgegeben. Eigentlich "Lesser GPL", passender wäre aber "Library GPL" ;-)

gzip_cnc benutzt ein
Komprimierungsverfahren, das nicht von ihm ist ...

Ja. Hast Du eigentlich alle angeschlossenen Lizenzen überprüft?
Aber eigentlich spielt die Artistic L. 2 überall ganz gut mit.

ich weiß jedoch nicht mal, welches, weil ich mehrere
ausprobiere und nehme, was ich kriegen kann ... ich
rufe diese Komprimierungsprogramme aber nur auf, habe
nichts von ihnen in mein Programm eingebaut

Das eine Entscheidungsfreiheit gegeben ist, spricht für Dich.

(anders
als die zlib bei den binary downloads von gzip_cncc,
wo sie ja wohl mit rein gelinkt sein muß - oder?).

Da wird sie dynamisch geladen. Es spielt also keine große Rolle, ob es unbedingt die ZLib ist, es kann auch eine andere sein, die sich gleich verhält.(Beispiel: Motif <-> Lesstif )
Anders bei statischem Linken, da könnte es zu Schwierigkeiten kommen (Im Fall ZLib aber nicht).

BTW: die ZLib Lizenz ist auch nicht ohne! Wie wäre es mit der?

Für welche(s) der beiden gzip_cnc*-Produkte?

Ich frage Dich, also für Deine.
(Und jetzt komm mir nicht mit dem Christian. Dein Name steht obendrüber, also mußt Du auch den Kopf dafür hinhalten ,-)

so short

Christoph (König der Schachtelsätze) Zurnieden

[Michael Schröpl]

Hallo /^Christ/,

Üblich ist es, sie als Datei 'LICENCE' mit in's
Paket zu packen.

hmpf ... ich mag license.html lieber, wenn schon der
ganze Rest der Dokumentation auch HTML ist ...

gzip_cnc benutzt ein
Komprimierungsverfahren, das nicht von ihm ist ...
Ja. Hast Du eigentlich alle angeschlossenen
Lizenzen überprüft?

Welche Lizenzbedingung muß ich erfüllen, um ein UNIX-
Systemkommando _aufzurufen_, falls es existiert?
Oder ein CPAN-Modul?
Ich kopiere ja nichts von beidem in meinen Quelltext.

Und ich bezeichne auch keines von beidem als meine
Erfindung, sondern weise explizit darauf hin, daß man
eines von beidem zusätzlich braucht, damit man mit
gzip_cnc etwas anfangen kann ...

Also so etwas nimmt mir glatt die Lust, selbst Software
zu publizieren.
Da muß ich mir echt überlegen, gzip_cnc wieder aus dem
Verkehr zu ziehen. Justistische Schwierigkeiten ist mir
der Versuch, dem Web etwas zu schenken, nicht wert.

Das eine Entscheidungsfreiheit gegeben ist, spricht
für Dich.

Naja, die Entscheidungsfreiheit ist nicht wirklich
gegeben - gzip_cnc klappert die beiden Möglichkeiten
in einer definierten Reihenfolge ab.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Hallo /^Christ/,

Hey, jetzt ende ich hier schon in einer Regex! ;-)

Üblich ist es, sie als Datei 'LICENCE' mit in's
Paket zu packen.

hmpf ... ich mag license.html lieber, wenn schon der
ganze Rest der Dokumentation auch HTML ist ...

Habe ja nur erwähnt, was üblich ist. ;-)
Sollte aber zumindest im Rootverzeichnis des Paketes liegen. Kann ja auch ein Link sein. (Funktioniert das jetzt eigentlich bei ZIP, das die Links beim Auspacken entsprechend dem Dateisystem gesetzt werden?)

gzip_cnc benutzt ein
Komprimierungsverfahren, das nicht von ihm ist ...
Ja. Hast Du eigentlich alle angeschlossenen
Lizenzen überprüft?

Welche Lizenzbedingung muß ich erfüllen, um ein UNIX-
Systemkommando _aufzurufen_, falls es existiert?

Normalerweise gar keine.

Oder ein CPAN-Modul?

Da sieht es schon anders aus. Kommt da auf die Lizenz des Moduls an.
Es reicht einmal da rein zu schauen. Sollte es eine der gängigen sein, sind die entsprechenden Bedingungen bei gnu.org gelistet.
Habe aber bei Modulen noch nie etwas hinderliches gefunden.
Es kann aber auch sein, das ein Modul kommerziell angeboten wird. (Wüßte jetzt zwar nicht, welches, aber egal) Das hätte dann eine andere Lizenz, die evt gegen irgendeine spezielle Verwendung spricht.

Ich kopiere ja nichts von beidem in meinen Quelltext.

Doch, das ist eine reguläre Einbindung. Schau mal in die Perlquellen, wie das funktioniert. Nämlich in etwa so, wie die Einbindung von Headern bei C, also komplett vor dem kompilieren.

Und ich bezeichne auch keines von beidem als meine
Erfindung, sondern weise explizit darauf hin, daß man
eines von beidem zusätzlich braucht, damit man mit
gzip_cnc etwas anfangen kann ...

Ja, das mußt Du schon ;-)

Also so etwas nimmt mir glatt die Lust, selbst Software
zu publizieren.

Dann bedank Dich bei IBM, MS und Co. Die sind das Schuld, das wir heute soviele Problem haben.

Aber das Du so schnell aufgibst, hätte ich ja nicht gedacht.

Da muß ich mir echt überlegen, gzip_cnc wieder aus dem
Verkehr zu ziehen.

'N bischen spät, ha?

Justistische Schwierigkeiten ist mir
der Versuch, dem Web etwas zu schenken, nicht wert.

Du schenkst nichts, denn Du willst Ruhm und Ehre ernten.
Und das ist nun nichts Schlechtes, an und für sich.

Und der Preis sind ein paar Lizenzlesungen und bei gnu.org nachschauen, ob die entspr Lizenz "OSI approved" ist und wenn nicht, warum nicht (sind meist nur ignorable Kleinigkeiten)

Das ist alles.
Na, ich bitte Dich! ;-)

Das eine Entscheidungsfreiheit gegeben ist, spricht
für Dich.

Naja, die Entscheidungsfreiheit ist nicht wirklich
gegeben - gzip_cnc klappert die beiden Möglichkeiten
in einer definierten Reihenfolge ab.

Der Nutzer hat die Quellen und kann das ändern (Ob er dazu in der Lage ist, ist unerheblich). Die Automatik ist nichts anderes, als eben eine Automatik.

so short

Christoph Zurnieden

[Michael Schröpl]

hi,

Sollte aber zumindest im Rootverzeichnis des Paketes
liegen.

tut sie jetzt.

Oder ein CPAN-Modul?
Da sieht es schon anders aus.
Kommt da auf die Lizenz des Moduls an.

Compress::Zlib

Version 1.16

13 December 2001

Copyright (c) 1995-2001 Paul Marquess. All rights

reserved.

This program is free software; you can redistribute

it and/or modify it under the same terms as Perl

itself.

(http://www.cpan.org/modules/by-module/Compress/Compress-Zlib-1.16.readme)

Deine Meinung dazu?

Ich will es aber gar nicht "verbreiten", ich liefere es
nicht selbst mit aus - es muß schon installiert sein.
Ich liefere nur das Bindeglied zwischen Zlib und Apache.

Es reicht einmal da rein zu schauen.

Mir nicht. Ich muß sie auch noch verstehen.

Also so etwas nimmt mir glatt die Lust, selbst
Software zu publizieren.
Dann bedank Dich bei IBM, MS und Co. Die sind das
Schuld, das wir heute soviele Problem haben.

"Danke, ...".

Aber das Du so schnell aufgibst, hätte ich ja nicht
gedacht.

Das meiste, was ich bisher getan habe, war Artikel
schreiben. Das verstößt gegen keine Software-Lizenz,
bringt dem Web aber genauso viel.

Da muß ich mir echt überlegen, gzip_cnc wieder
aus dem Verkehr zu ziehen.
'N bischen spät, ha?

Wieso das?

Justistische Schwierigkeiten ist mir
der Versuch, dem Web etwas zu schenken, nicht
wert.
Du schenkst nichts, denn Du willst Ruhm und Ehre
ernten.

Ich will nicht von Dir die (berechtigte) Kritik hören,
ein Tool, das ich selbst geschrieben habe und auf mei-
ner Domain einsetze, nicht als Open Source publiziert,
sondern in der Schublade verrotten lassen zu haben.

(Die Self-Suche ist so ein Tool, in gewisser Weise.)

Und der Preis sind ein paar Lizenzlesungen und bei
gnu.org nachschauen, ob die entspr Lizenz "OSI
approved" ist und wenn nicht, warum nicht (sind
meist nur ignorable Kleinigkeiten)
Das ist alles.
Na, ich bitte Dich! ;-)

Das ist mir schon zuviel.

Ich will kein Jurist werden müssen, um eine Idee aus-
sprechen zu dürfen. Dann bin ich lieber still.

Ich habe noch viele andere Bereiche, die seit Jahren
darauf warten, mehr Zeit zugeordnet zu bekommen ...

Frustrierte Grüße
            Michael

[Christoph Zurnieden]

Hallo,

Oder ein CPAN-Modul?
Da sieht es schon anders aus.
Kommt da auf die Lizenz des Moduls an.

Compress::Zlib

Version 1.16

13 December 2001

Copyright (c) 1995-2001 Paul Marquess. All rights

reserved.

This program is free software; you can redistribute

it and/or modify it under the same terms as Perl

itself.

(http://www.cpan.org/modules/by-module/Compress/Compress-Zlib-1.16.readme)

Deine Meinung dazu?

I.O., siehe auch:
http://www.gnu.org/licenses/license-list.html

The license of Perl.
    This license is the disjunction of the Artistic License and the GNU GPL--in other words, you can choose
    either of those two licenses. It qualifies as a free software license, but it may not be a real copyleft.
    It is compatible with the GNU GPL because the GNU GPL is one of the alternatives.

We recommend you use this license for any Perl 4 or Perl 5 package you write, to promote coherence and
    uniformity in Perl programming. Outside of Perl, we urge you not to use this license; it is better to use
    just the GNU GPL.

Ich will es aber gar nicht "verbreiten", ich liefere es
nicht selbst mit aus - es muß schon installiert sein.
Ich liefere nur das Bindeglied zwischen Zlib und Apache.

Das ist in dem speziellem Fall egal.
(Hat was mit dem Unterschied zwischen dynamischem und statischem Linken zu tun)

Da muß ich mir echt überlegen, gzip_cnc wieder
aus dem Verkehr zu ziehen.
'N bischen spät, ha?

Wieso das?

Ist raus und unter Artistic Licence 2.
Ein Zurück gibt es nicht mehr.

Justistische Schwierigkeiten ist mir
der Versuch, dem Web etwas zu schenken, nicht
wert.
Du schenkst nichts, denn Du willst Ruhm und Ehre
ernten.

Ich will nicht von Dir die (berechtigte) Kritik hören,
ein Tool, das ich selbst geschrieben habe und auf mei-
ner Domain einsetze, nicht als Open Source publiziert,
sondern in der Schublade verrotten lassen zu haben.

(Die Self-Suche ist so ein Tool, in gewisser Weise.)

Da verstehe ich jetzt den genauen Zusammenhang zu "Ruhm und Ehre" nicht.
Was gibt es daran auszusetzen?
Ist doch auf jeden Fall besser als nur hinter der Kohle her zu sein.

Und der Preis sind ein paar Lizenzlesungen und bei
gnu.org nachschauen, ob die entspr Lizenz "OSI
approved" ist und wenn nicht, warum nicht (sind
meist nur ignorable Kleinigkeiten)
Das ist alles.
Na, ich bitte Dich! ;-)

Das ist mir schon zuviel.

Ja, das wirst Du schon machen müssen, wenn Du Produkte anderer Leute benutzt.
Du hättest den gzip Algorithmus ja schließlich auch selber schreiben können, der ist schließlich offener Standard.
Aber das wolltest/konntest Du nicht, also hast Du die Gelegenheit am Schopf gepackt und eine bereits vorhandene Implementation benutzt.
Das einzige was Du dann versäumt hast, war die Lizenz zu prüfen, ob die Dir paßt. Dafür hast Du dann viel Arbeit gespart!

Selbst bei dem Lizenzüberprüfen hat Dir schon jemand viel, eigentlich fast alle, Arbeit abgenommen. Schau einfach mal auf den Link, den ich weiter oben gesetzt habe.

Ich will kein Jurist werden müssen, um eine Idee aus-
sprechen zu dürfen. Dann bin ich lieber still.

Eigentlich sollte ich hier ja vehement wiedersprechen, aber wenn ich mir so anschaue, was im Augenblick im Patent- und Urheberrecht so alles abgeht insbesondere im Softwarebereich, dann kann ich Dich durchaus verstehen.

Aber deswegen gleich die Flinte in's Korn werfen?
Das freut doch höchstens den Zahnarzt! ;-)

Ich habe noch viele andere Bereiche, die seit Jahren
darauf warten, mehr Zeit zugeordnet zu bekommen ...

Oh ja, wem sagst Du das *sigh* ;-)

so short

Christoph Zurnieden

PS:
ich habe gerade mal eine Mime-Tabelle reingebastelt (funktioniert wie üblich über Links auf das eigentliche Programm und Abfrage auf argv[0]). Habe das etwas arg kompliziert gebaut. Schmeiß den Scheiß eben raus und mach das ordentlich. Paket dann mor^H^H^Hheute mittag oder so.
Links werden bei der Installation auf *nix von 'make install' erzeugt.
Da das Programm für Leute gedacht ist, die wahrscheinlich noch nicht einmal einen Shellzugang haben, ist das wohl etwas oversized, aber zum Testen ganz nett.
Ah, ich glaube, ich habe eine bessere Idee ;-)
CZ

[Michael Schröpl]

Hi,

ich habe gerade mal eine Mime-Tabelle reingebastelt
(funktioniert wie üblich über Links auf das
eigentliche Programm und Abfrage auf argv[0]).

hatten wir nicht geklärt, daß "SetEnv" doch nicht "böse" wäre?

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

ich habe gerade mal eine Mime-Tabelle reingebastelt
(funktioniert wie üblich über Links auf das
eigentliche Programm und Abfrage auf argv[0]).

hatten wir nicht geklärt, daß "SetEnv" doch nicht "böse" wäre?

Dann habe ich irgendwas nicht mitbekommen  ;-)
(Die Mime-Tabelle wäre aber eh per default ausgeschaltet gewesen)

Aber meine Dokumentation vom Apachen 1.3.23 sagt folgendes

SetEnv directive

Syntax: SetEnv env-variable value
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_env
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?

Allerdings bräuchtest Du eigentlich sogar SetEnvIf:

SetEnvIf directive

Syntax: SetEnvIf attribute regex env-variable[=value] [env-variable[=value]] ...
Default: none
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_setenvif
Compatibility: Apache 1.3 and above; the Request_Protocol keyword and environment-variable matching are only
available with 1.3.7 and later; use in .htaccess files only supported with 1.3.13 and later

Und das ist, wie man sieht,  erst ab 1.3.13 in der .htaccess möglich.
(Ich kann das in ./configure abfragen, so ist das nicht, aber der Aufwand ... ;-).

Also meine Frage: sind die Dinger so alt, daß man sie getrost ignorieren kann?

so short

christoph Zurnieden

[Michael Schröpl]

Hallo Christoph,

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.
(Es sei denn, mod_env ist als Apache-Standard-Modul
überhaupt nicht installiert ... wie beispielsweise
genau bei meinem Provider, gnlpfts.)

SetEnv directive
Override: FileInfo

Genau das meinte ich.

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 (!) verwenden würde, hätte ich darüber
milde gelächelt ...

Allerdings bräuchtest Du eigentlich sogar SetEnvIf:

Wozu?

Ich kann doch mehrere MIME-Typen durch mehrere separate
Einbindungen lösen und jeweils innerhalb der <Files>-
Klammer eine andere SetEnv-Direktive verwenden.

Also meine Frage: sind die Dinger so alt, daß man
sie getrost ignorieren kann?

Das kommt darauf an.

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. ;-)

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.

Insofern habe ich es für gzip_cnc 1.07 einfach mal
eingebaut:
   http://www.schroepl.net/projekte/gzip_cnc/changes.htm#v1.07

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

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

[Michael Schröpl]

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

[Christoph Zurnieden]

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

[Michael Schröpl]

Hallo Christoph,

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.

wie willst Du merken, daß getenv nicht "funktioniert"
hat? Das Problem ist ja, daß Du einen Wert brauchst.

Ich mache es anders herum: Ich überdecke mit ENV{}
die eingebrannten Default-Werte, falls "defined".

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 ;-)

... weil Du glaubtest, ich würde ZIP-Archive nur am
Ende erweitern ... ja, ist nicht ...

Warum mußt Du ihn eigentlich anpassen? Wie wäre es
mit einem einfachem Link von gzip_cnc.zip auf die
jeweilige Version?

Was ändert das für Dich? Wenn Du keinen Link auf die
aktuellste Version hast, der von einem bisherigen ab-
weichst, findest Du die Datei nicht.

Was ich tun müßte, wäre ein Archiv aufzubauen wie der
Apache selbst ... dummerweise hat mein Provider gerade
Directory Browser für den gesamten Apache abgeschaltet,
weil "das eh keiner braucht und es bloß Fehler gibt,
da wir ja vergessen haben, ein "/images" zu definieren
(letzteres habe ich für meinen Webspace gefixed, aber
...)

Na, Mimetype immer noch fest? ;-)
Ja, weil ich außer HTML keinen Bedarf sehe.
Mmh...
Eigentlich für fast alle text/*, oder?

Wer liefert so etwas in nennenswerten Stückzahlen aus?
(Und kann nicht mal schnell einen HTML-body drum herum
mache und <pre> verwenden.)

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 ...
...
Müßte man mal recherchieren seit wann.

Da bin ich ja mal gespannt.

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.

Ja. Ich kann einen 404er senden, zusammen mit einer
Redirection via "Location:". Bloß: Wenn der Browser
dann diese Redirection ausführt, bekommt er _dann_
einen HTTP-Status 200 geliefert - dagegen kann ich
als Nicht-Modul nichts machen.

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ß.

Völlig korrekt - es geht ja auch darum, ob mein
Links-Checker noch funktioniert oder nicht.

Also: Ist implementiert in 1.08.

(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.

Ich wiederhole:
Das sind bei mir _nicht_ zwei getrennte Fälle.

Was mache ich denn, wenn ich auf den konfigurierten URL
des 404-Handlers weiterleiten muß? Ich kann da nur
entweder 302 oder 404 senden ... ich habe mich jetzt
mal für 404 entschieden, in der Hoffnung, daß dann die
Clients den "Location:"-Header trotzdem verstehen.

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 ;-)

Das ist eine Redirection ...

Wenn Du einen Filter laufen läßt

Da ist ein Spam-Filter von GMX drin, ja. Nix Eigenes.

/^Subject:[\s]*(Re:)*[\s]*88a43603fcfc2f7e7c6646cd4b89180a/
einigen?

So mächtig ist das gar nicht, was ich da tun kann.

Aber Du kannst natürlich auch eine Mail direkt an
"mich" senden ... ;-)

Wie willst Du den Filter dort einbauen?
Im Apache geht es nur so, wie mod_gzip das macht
(denke ich);
Nun, den Filter wollte ich genauso einbauen, wie
gzip_cncc auch.

Äh, und wie greifst Du dann auf den Inhalt der
dynamisch erzeugten Seite zu?

Du kannst diese ja nicht via HTTP-GET absaugen, weil
Du damit denselben Handler wieder aufrufst.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

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.

wie willst Du merken, daß getenv nicht "funktioniert"
hat? Das Problem ist ja, daß Du einen Wert brauchst.

getenv() liefert entweder eine Pointer auf den Wert ab, oder NULL wenn nix da ist.
Ist das in Perl anders?

Ich mache es anders herum: Ich überdecke mit ENV{}
die eingebrannten Default-Werte, falls "defined".

Naja, wie Du die vorbelegten Werte benutzt ist eigentlich egal. Aber ich finde es nicht ganz ungeschickt von Dir, der Shell das Speichermanagment zu überlassen. Keine schlechte Idee! ;-)

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 ;-)

... weil Du glaubtest, ich würde ZIP-Archive nur am
Ende erweitern ... ja, ist nicht ...

Ich nicht, aber wget ;-)

Warum mußt Du ihn eigentlich anpassen? Wie wäre es
mit einem einfachem Link von gzip_cnc.zip auf die
jeweilige Version?

Was ändert das für Dich? Wenn Du keinen Link auf die
aktuellste Version hast, der von einem bisherigen ab-
weichst, findest Du die Datei nicht.

Ja, war mein Fehler, ich hatte einen normalen FTP Server im Hinterkopf.
Sorry.

Was ich tun müßte, wäre ein Archiv aufzubauen wie der
Apache selbst ... dummerweise hat mein Provider gerade
Directory Browser für den gesamten Apache abgeschaltet,
weil "das eh keiner braucht und es bloß Fehler gibt,
da wir ja vergessen haben, ein "/images" zu definieren
(letzteres habe ich für meinen Webspace gefixed, aber
...)

Au Mann. *sigh*

Nicht doch evt, wie wär's, vielleicht, ein CVS bei Sourceforge? ;-)
Das kann man bei denen wenigstens noch per Kommandozeile abfragen.

Na, Mimetype immer noch fest? ;-)
Ja, weil ich außer HTML keinen Bedarf sehe.
Mmh...
Eigentlich für fast alle text/*, oder?

Wer liefert so etwas in nennenswerten Stückzahlen aus?

es gibt:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/
sowie noch einige hiervon:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/
und etwas:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/
nicht zu vergessen eine Prise:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/model/

Eine Menge. Alles nicht nennenswert?

(Und kann nicht mal schnell einen HTML-body drum herum
mache und <pre> verwenden.)

Gut, auch wieder wahr ;-)
Außerdem verdränge ich immer wieder gerne die Probleme mit externem Javascript/CSS ;-)

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 ...
...
Müßte man mal recherchieren seit wann.

Da bin ich ja mal gespannt.

Das hatte ich befürchtet, daß Du "man" auf mich beziehst ;-)

BTW: man versicherte mir von anderer Stelle, das gmtime() von Perl richtig funktioniert, also stets auf GMT umrechnet, bei mir ist trotzdem eine Stunde Unterschied. (Nein, die locales sind alle korrekt gesetzt und der Rest funktioniert auch. Mag aber natürlich trotzdem nichts heißen ;-)

Würde sowieso eine Weltzeit anempfehlen. In Zeiten von modernster Kommunikationsmitteln, globaler Märkte und Concorde sind Zeitzonen doch eh ein verstaubtes Relikt aus längst vergang'nen Tagen, oder? ;-)

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.

Ja. Ich kann einen 404er senden, zusammen mit einer
Redirection via "Location:".

Das ist aber nicht nach Standard, oder?

Bloß: Wenn der Browser
dann diese Redirection ausführt, bekommt er _dann_
einen HTTP-Status 200 geliefert - dagegen kann ich
als Nicht-Modul nichts machen.

Das ist dann die Folgeerscheinung vom Redirect und an der Stelle natürlich völlig korrekt.

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ß.

Völlig korrekt - es geht ja auch darum, ob mein
Links-Checker noch funktioniert oder nicht.

Also: Ist implementiert in 1.08.

Überzeugt, oder nur genervt? ;-)

(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.

Ich wiederhole:
Das sind bei mir _nicht_ zwei getrennte Fälle.

Da steht aber dann der Standard dagegen.
Ich habe das folgendermaßen gelöst:
Wenn nix gefunden wurde && eine eigene 404-Datei durch einen kompletten und gültigen Pfad definiert ist, sendet er den passenden Header, liest die Datei aus und hängt sie dran.

Was mache ich denn, wenn ich auf den konfigurierten URL
des 404-Handlers weiterleiten muß?

Mußt Du doch gar nicht.

Ich kann da nur
entweder 302 oder 404 senden ... ich habe mich jetzt
mal für 404 entschieden, in der Hoffnung, daß dann die
Clients den "Location:"-Header trotzdem verstehen.

Naja ;-)

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 ;-)

Das ist eine Redirection ...

Wenn Du einen Filter laufen läßt

Da ist ein Spam-Filter von GMX drin, ja. Nix Eigenes.

Och, der ist nicht schlecht habe ich festgestellt.

/^Subject:[\s]*(Re:)*[\s]*88a43603fcfc2f7e7c6646cd4b89180a/
einigen?

So mächtig ist das gar nicht, was ich da tun kann.

Doch, ist es.
Habe ich auch nicht geglaubt, dann aber mal ausprobiert ;-)
War denen wohl zu kompliziert die Sache einzuschränken ;-)

(Aber ob die Regex oben funktioniert, habe ich nicht)

Aber Du kannst natürlich auch eine Mail direkt an
"mich" senden ... ;-)

Zuviele Variablen ;-)
http://mzurnieden.bei.t-online.de/pubkey.asc

Wie willst Du den Filter dort einbauen?
Im Apache geht es nur so, wie mod_gzip das macht
(denke ich);
Nun, den Filter wollte ich genauso einbauen, wie
gzip_cncc auch.

Äh, und wie greifst Du dann auf den Inhalt der
dynamisch erzeugten Seite zu?

Wollte ich eigentlich gar nicht, sondern nur einen Stream verarbeiten.
Ich greife also nicht auf die Seite zu, sondern die Seite auf mich.

Das könnte z.B. via HTTP-POST funktionieren.

Aber, wie ich das gerade so hinschreibe kommen mir doch mein Zweifel.

Ich schick Dir mal eben die Datei (allerdings ohne das spezielle Subject ;-) an die GMX Adresse.

BTW: bevor Du wieder damit kommst, daß es nicht für Programmierer sei: simple Datenbankabfragen sind doch mittlerweile recht gängig seit viele Provider CGI gleich mit MySQL anbieten (müssen ;-). Allerdings alles aus den Standardpaketen und da ist mod_gzip nicht drin. (Warum eigentlich nicht? Oder ist es mittlerweile? Zumindest nicht in 1.3.23.)
Und die eine Zeile mit dem POST sollte doch wohl jeder hinkriegen, der auch eine simple Datenbankabfrage hinbekommen hat, oder?

Du kannst diese ja nicht via HTTP-GET absaugen, weil
Du damit denselben Handler wieder aufrufst.

Ganz so blöd bin ich auch nicht!
Na gut, schon, aber auch nicht jedesmal ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Tag,

Ist das in Perl anders?

Nein. Nur halt 'undef' statt 'NULL'.

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 ...
...
Müßte man mal recherchieren seit wann.

Da bin ich ja mal gespannt.

Das hatte ich befürchtet, daß Du "man" auf mich beziehst ;-)

AFAIK ist das POSIX-Modul seit 5.0 dabei. Die frueheste Version, die ich
finden kann, ist die aus Perl 5.003:

http://search.cpan.org/search?dist=perl5.003

Allerdings alles aus den Standardpaketen und da ist mod_gzip nicht drin.
(Warum eigentlich nicht? Oder ist es mittlerweile? Zumindest nicht in
1.3.23.)

Politische Gruende... Kevin Kiley (der Autor von mod_gzip) und die Apache Group
haben sich ziemlich heftig gestritten. Wenn es dich interessiert, kannst du es
in den Listen-Archiven nachlesen.

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Ist das in Perl anders?

Nein. Nur halt 'undef' statt 'NULL'.

Dann seh ich das Problem wirklich nicht.

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 ...
...
Müßte man mal recherchieren seit wann.

Da bin ich ja mal gespannt.

Das hatte ich befürchtet, daß Du "man" auf mich beziehst ;-)

AFAIK ist das POSIX-Modul seit 5.0 dabei. Die frueheste Version, die ich
finden kann, ist die aus Perl 5.003:

http://search.cpan.org/search?dist=perl5.003

Mein lieber Christian: Du bist meines ewigen Dankes sicher!

Ich hätte noch nicht einmal gewuß, wo anzufangen. (Na gut, search.cpan.org hätte ich noch gekannt, aber das war's auch schon ;-)

Allerdings alles aus den Standardpaketen und da ist mod_gzip nicht drin.
(Warum eigentlich nicht? Oder ist es mittlerweile? Zumindest nicht in
1.3.23.)

Politische Gruende... Kevin Kiley (der Autor von mod_gzip) und die Apache Group
haben sich ziemlich heftig gestritten. Wenn es dich interessiert, kannst du es
in den Listen-Archiven nachlesen.

Politik?
Nein danke, mir reicht schon die, um die man nicht herumkommt.

so short

Christoph Zurnieden

[Christian Kruse]

Tag Christoph,

Mein lieber Christian: Du bist meines ewigen Dankes sicher!

*g*

Ich hätte noch nicht einmal gewuß, wo anzufangen. (Na gut, search.cpan.org
hätte ich noch gekannt, aber das war's auch schon ;-)

Naja, search.cpan.org ist IMHO die allererste Anlaufstelle fuer sowas. Aber wie
gesagt, AFAIK ist es sogar ab 5.000 dabei, 5.003 ist nur die erste
Zusammenstellung, die dort veroeffentlicht wurde.

Politik?
Nein danke, mir reicht schon die, um die man nicht herumkommt.

:)
Full ACK.

Gruesse,
 CK

[Michael Schröpl]

Hallo Christoph,

Na, Mimetype immer noch fest? ;-)
Ja, weil ich außer HTML keinen Bedarf sehe.
Mmh...
Eigentlich für fast alle text/*, oder?
Wer liefert so etwas in nennenswerten Stückzahlen aus?
es gibt:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/
sowie noch einige hiervon:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/
und etwas:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/
nicht zu vergessen eine Prise:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/model/
Eine Menge. Alles nicht nennenswert?

Alles nicht nennenswerte Anteile meines Web-Traffic.
Eher alles zusammen genau Null Prozent.

Bei "Application" würde ich Komprimierung noch am
ehesten verstehen (das sind wahrscheinlich große
Dateien und vermutlich auch gut komprimierbar), aber
die werden nur in wenigen Fällen dynamisch im Browser
interpretiert, können also auch geZIPt werden.

Und ein paar Anwendungen verwenden ja auch wieder
ihre eigenen Archiv-Formate (z. B. *.jar").

BTW: man versicherte mir von anderer Stelle, das
gmtime() von Perl richtig funktioniert, also stets
auf GMT umrechnet,

Dachte ich eigentlich auch - fein.

Würde sowieso eine Weltzeit anempfehlen.
In Zeiten von modernster Kommunikationsmitteln,
globaler Märkte und Concorde sind Zeitzonen doch eh
ein verstaubtes Relikt aus längst vergang'nen Tagen,
oder? ;-)

Wenn Du dann bitte auch noch das Beleuchtungsproblem
gleich mit lösen würdest ... ?

Ja. Ich kann einen 404er senden, zusammen mit
einer Redirection via "Location:".
Das ist aber nicht nach Standard, oder?

Viel schlimmer: Die Browser verstehen es nicht.
Weia, das muß wieder raus.

Bloß: Wenn der Browser
dann diese Redirection ausführt, bekommt er
_dann_ einen HTTP-Status 200 geliefert - dagegen
kann ich als Nicht-Modul nichts machen.
Das ist dann die Folgeerscheinung vom Redirect und
an der Stelle natürlich völlig korrekt.

Wenn die Browser es so machen würden, wäre ich glücklich. Sie ignorieren aber die Weiterleitung.

Also: Ist implementiert in 1.08.
Überzeugt, oder nur genervt? ;-)

Eigentlich überzeugt. Ich fürchte nur, das Problem ist
gar nicht lösbar.

Ich habe das folgendermaßen gelöst:
Wenn nix gefunden wurde && eine eigene 404-Datei
durch einen kompletten und gültigen Pfad definiert
ist, sendet er den passenden Header, liest die Datei
aus und hängt sie dran.

Genau das kann ich aber nicht.

Denn damit schließe ich alle 404-handler, die über URLs
arbeiten _müssen_ (weil sie selbst dynamische Ausgaben
erzeugen), aus.

Das ist der Grund dafür, wieso der 404-Handler in
gzip_cnc als URL definiert ist und nicht als Pfad.

Die Alternative wäre wirklich, dort einen Pfad ein-
zutragen. Wäre sogar nicht so furchtbar schlimm, weil
gzip_cnc einem intelligenten 404-Handler ohnehin nicht
das Environment aufbauen kann, welches dieses auswer-
ten wollen würde ... was meinst Du dazu?

Aber Du kannst natürlich auch eine Mail direkt an
"mich" senden ... ;-)
Zuviele Variablen ;-)

Nicht wirklich (so, wie der SMTP-Server hier konfigu-
riert ist) ...

Äh, und wie greifst Du dann auf den Inhalt der
dynamisch erzeugten Seite zu?
Wollte ich eigentlich gar nicht, sondern nur einen
Stream verarbeiten.
Ich greife also nicht auf die Seite zu, sondern die
Seite auf mich.
Das könnte z.B. via HTTP-POST funktionieren.

Ich habe ungefähr kein Wort davon verstanden ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Michael Schröpl]

... hallo nochmal,

Ja. Ich kann einen 404er senden, zusammen mit
einer Redirection via "Location:".
Das ist aber nicht nach Standard, oder?
Viel schlimmer: Die Browser verstehen es nicht.
Weia, das muß wieder raus.

ich habe gerade noch etwas gebastelt.

Das ist der Grund dafür, wieso der 404-Handler in
gzip_cnc als URL definiert ist und nicht als Pfad.

Genau das gibt es so nicht mehr.

Die Variable für den 404-Handler kann bei mir nun
_wahlweise_ einen URL (beginnend mit "http:") _oder_
einen Dateinamen (alles andere) enthalten.

1. Ist das ein URL, dann sendet gzip_cnc eine HTTP-
   302-Weiterleitung dorthin, hängt jedoch den URL
   der ursprünglich angeforderten Seite als Parameter
   "url" an den 404-handler-URL dran.
   Wenn dies also ein Programm ist (oder auch nur ein
   SSI-Dokument), kann es diesen Parameter extrahieren
   und auswerten.

2. Ist es kein URL, dann liefert gzip_cnc den Inhalt
   dieser Datei selbst aus (falls das klappt), und
   zwar mit einem HTTP-Statuscode von 404.
   Der kommt auch so bei den Browsern an; lustigerweise
   schreibt der Apache allerdings einen Statuscode von
   200 (!) in sein access_log (keine Ahnung, wieso).

3. Hat das nicht geklappt oder war kein Error-Handler
   angegeben, dann sendet gzip_cnc sein eigenes klei-
   nes Fehlerdokument (_mit_ dem Namen des angeforder-
   ten URL), ebenfalls mit HTTP-Statuscode 404.

Auf diese Weise kann der Benutzer wählen:
a) Benötigt er zur Fehlerbehandlung eine Funktion des
   Webservers (was z. B. bei mir selbst der Fall ist:
   Mein 404-Handler möchte eigentlich gerne language
   negotiated werden), dann muß er sich mit der 302-
   Weiterleitung zufrieden geben.
b) Reicht ihm jedoch ein statisches Dokument, dann kann
   dieses mit dem korrekten HTTP-Status 404 ausgelie-
   fert werden.

Schön finde ich das alles nicht (zumal ich jetzt noch
die Dokumentation entsprechend umschreiben muß) ...
aber besser kriege ich es im Moment nicht hin.
Immerhin funktioniert es nun wieder mit allen wesent-
lichen Browsern.

Dafür, daß dieser Handler so wenige Informationen vom
Apache kriegt, muß er ganz schön viel HTTP machen ...
gnlpfts.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christian Kruse]

Tag Michael,

Der kommt auch so bei den Browsern an; lustigerweise
   schreibt der Apache allerdings einen Statuscode von
   200 (!) in sein access_log (keine Ahnung, wieso).

Weil fuer den Apache der Request erfolgreich war. Er hat die Datei
(gzip_cnc.pl) gefunden, sie ist ausfuehrbar und schickt korrekte Header. Wenn
du den Log-Eintrag haben willst, koennte das, denke ich, mit einem NPH-Script
funktionieren. NPH steht fuer 'No Parsed Headers'. Es Unterscheidet sich halt
darin, dass man einen kompletten und validen HTTP-Header ausgeben muss. Inkl.
erster Zeile allá

HTTP/1.[10] 200 Ok

Der Apache fasst die Header danach nicht mehr an. NPH-Scripts heissen beim
Apachen einfach 'nph-<scriptname>.pl' :) Ach ja, CGI.pm unterstuetzt diesen Modus
auch:

use CGI qw(-nph);

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Das ist der Grund dafür, wieso der 404-Handler in
gzip_cnc als URL definiert ist und nicht als Pfad.

Genau das gibt es so nicht mehr.

Die Variable für den 404-Handler kann bei mir nun
_wahlweise_ einen URL (beginnend mit "http:") _oder_
einen Dateinamen (alles andere) enthalten.

1. Ist das ein URL, dann sendet gzip_cnc eine HTTP-
      302-Weiterleitung dorthin, hängt jedoch den URL
      der ursprünglich angeforderten Seite als Parameter
      "url" an den 404-handler-URL dran.
      Wenn dies also ein Programm ist (oder auch nur ein
      SSI-Dokument), kann es diesen Parameter extrahieren
      und auswerten.

Damit hast Du immer noch einen 302 statt des für "File not found" vorgesehenem 404.
(Außerdem müßte damit jemand seinen mühsam zusammengebastelten 404 wieder umbauen ;-)

2. Ist es kein URL, dann liefert gzip_cnc den Inhalt
      dieser Datei selbst aus (falls das klappt), und
      zwar mit einem HTTP-Statuscode von 404.

Ja, so habe ich das.

Der kommt auch so bei den Browsern an; lustigerweise
   schreibt der Apache allerdings einen Statuscode von
   200 (!) in sein access_log (keine Ahnung, wieso).

Er bekommt davon ja nichts mit, aber auch keinen Fehler, also 200.
Nehme aber an, daß das irgendein Konzeptionsfehler im Apachen ist.

3. Hat das nicht geklappt oder war kein Error-Handler
      angegeben, dann sendet gzip_cnc sein eigenes klei-
      nes Fehlerdokument (_mit_ dem Namen des angeforder-
      ten URL), ebenfalls mit HTTP-Statuscode 404.

Ja, diesen Ausweg hatte ich mir auch freigehalten.

Auf diese Weise kann der Benutzer wählen:
a) Benötigt er zur Fehlerbehandlung eine Funktion des
   Webservers (was z. B. bei mir selbst der Fall ist:
   Mein 404-Handler möchte eigentlich gerne language
   negotiated werden),

Muß das denn wieder sein? *sigh*

dann muß er sich mit der 302-
   Weiterleitung zufrieden geben.
b) Reicht ihm jedoch ein statisches Dokument, dann kann
   dieses mit dem korrekten HTTP-Status 404 ausgelie-
   fert werden.

404 sind doch imer statisch, oder? Welche Spielerei will man da noch einbauen?
Sprache? Gut, das geht aber auch einfach in gzip_cnc. (Content negotiation auf Sprache geht, da 404 in verschiedenen Sprachen auch nur als statische Dateien rumhängen sollten)
Sonst noch was?
Also mehr als die Möglichkeit "'blabla.html' wurde nicht gefunden, bitte überprüfen sie die Schreibweise" in allen ca 5.000 Spracehn und Dialekten der Welt anbieten zu können sehe ich wirklich nicht.

Aber ich mag mich irren und/oder irgendetwas übersehen haben.

Schön finde ich das alles nicht (zumal ich jetzt noch
die Dokumentation entsprechend umschreiben muß) ...

Jaja, Programmierer und Dokumentation ... ;-)))

aber besser kriege ich es im Moment nicht hin.
Immerhin funktioniert es nun wieder mit allen wesent-
lichen Browsern.

Immerhin!
(Bleibt noch die Frage, was Du unter "wesentlichen Browsern" verstehst. Aber eigentlich möcht' ich das auch wiederum gar nicht wissen ;-)

Dafür, daß dieser Handler so wenige Informationen vom
Apache kriegt, muß er ganz schön viel HTTP machen ...
gnlpfts.

Na, soviel ist es nun wirklich nicht. Ich bitte Dich! ;-)

Und außerdem: ja und? ;-)))

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

1. Ist das ein URL, dann sendet gzip_cnc eine HTTP-
      302-Weiterleitung dorthin, hängt jedoch den URL
      der ursprünglich angeforderten Seite als Parameter
      "url" an den 404-handler-URL dran.

Damit hast Du immer noch einen 302 statt des für
"File not found" vorgesehenem 404.

Tja, mehr geht einfach nicht, wenn man kein Modul ist
und keine internen Subrequests machen kann.
Mach Du mal den Browser klar, daß sie im Falle eines
404 trotzdem eine Redirection ausführen sollen ...

(Außerdem müßte damit jemand seinen mühsam
zusammengebastelten 404 wieder umbauen ;-)

Meinst Du, _mir_ gefällt das? Deshalb jammere ich ja
so ...

Mein 404-Handler möchte eigentlich gerne language
   negotiated werden),
Muß das denn wieder sein? *sigh*

Klar muß das sein. Der Apache unterstützt an dieser
Stelle einen URL. Und es gibt durchaus Gründe dafür.

404 sind doch imer statisch, oder?
Welche Spielerei will man da noch einbauen?

1. Ein Programm an dieser Stelle könnte mir eine Mail
   senden etc. - vielleicht habe ich ja keinen Zugriff
   auf ein error_log.

2. Ein Programm an dieser Stelle könnte den Referrer
   untersuchen und dadurch erkennen, ob ein broken link
   innerhalb meiner eigenen Domain vorliegt oder ob das
   ein mißlungener Einsprung von außen war (oder gar
   ein Tippfehler in der URL-Zeile, wobei ein leerer
   Referrer mitgeschickt würde) und dann den ausgegebe-
   nen Text darauf bedingt formulieren.

Sprache? Gut, das geht aber auch einfach in gzip_cnc.
(Content negotiation auf Sprache geht, da 404 in
verschiedenen Sprachen auch nur als statische
Dateien rumhängen sollten)

Dazu müßte gzip_cnc aber die komplette Negotiation mit
mehreren Endungen gleichzeitig durchführen!

Beispielsweise müßte es meine ErrorDocument-Datei mit
dem Namen "missing.htm.shtml.de" verstehen!
Ich will nämlich Sprachvarianten _und_ SSI in Kombi-
nation verhandeln - und ich will gleichzeitig die
Endung vor den Besuchern verstecken, die diese Datei
mal direkt ansprechen (sie ist _auch_ verlinkt).

Also mehr als die Möglichkeit "'blabla.html' wurde
nicht gefunden, bitte überprüfen sie die
Schreibweise" in allen ca 5.000 Spracehn und
Dialekten der Welt anbieten zu können sehe ich
wirklich nicht.

Ich auch nur in zwei (deutsch und englisch).
Aber was würdest Du als englischsprachiger Besucher
meiner gzip_cnc-Seiten mit diesem Text hier anfangen:

http://www.schroepl.net/missing.htm

Das ist halt _etwas_ mehr als "Überprüfen Sie die
Schreibweise für etwas, das Sie gar nicht selbst ge-
schrieben haben" (was ich übrigens bescheuert finde).

Schön finde ich das alles nicht (zumal ich jetzt
noch die Dokumentation entsprechend umschreiben
muß) ...
Jaja, Programmierer und Dokumentation ... ;-)))

Meine hast Du gesehen - ich Deine noch nicht ...

(Bleibt noch die Frage, was Du unter "wesentlichen
Browsern" verstehst. Aber eigentlich möcht' ich das
auch wiederum gar nicht wissen ;-)

Die neuesten Versionen von Mozilla, Opera, M$IE und
Netscape 4.

Dafür, daß dieser Handler so wenige Informationen
vom Apache kriegt, muß er ganz schön viel HTTP
machen ... gnlpfts.
Na, soviel ist es nun wirklich nicht. Ich bitte Dich! ;-)
Und außerdem: ja und? ;-)))

Es geht ja nicht darum, daß ich zu faul wäre, es zu
programmieren.
Aber je mehr HTTP-Zeug in das Programm hinein muß,
desto abschreckender wirkt die Dokumentation für po-
tentielle Benutzer, die selbst nicht programmieren
können. Und es wird auch immer schwerer für sie,
eigene Fehler bei der Installation zu finden.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

1. Ist das ein URL, dann sendet gzip_cnc eine HTTP-
      302-Weiterleitung dorthin, hängt jedoch den URL
      der ursprünglich angeforderten Seite als Parameter
      "url" an den 404-handler-URL dran.

Damit hast Du immer noch einen 302 statt des für
"File not found" vorgesehenem 404.

Tja, mehr geht einfach nicht, wenn man kein Modul ist
und keine internen Subrequests machen kann.
Mach Du mal den Browser klar, daß sie im Falle eines
404 trotzdem eine Redirection ausführen sollen ...

Soll er ja nicht. 404 ist "Datei nicht gefunden".
Der IE hat (hatte?) dafür sogar eine Standarddatei, falls außer dem 404 nix kommt (wohl wg IIS >;-> )

Mein 404-Handler möchte eigentlich gerne language
   negotiated werden),
Muß das denn wieder sein? *sigh*

Klar muß das sein. Der Apache unterstützt an dieser
Stelle einen URL. Und es gibt durchaus Gründe dafür.

Welche?
Die Sprache hast Du eh entweder im UA oder eben gar nicht.
UA kannst Du abfragen und dementsprechend die 404-Datei nach Sprache auswählen.

404 sind doch imer statisch, oder?
Welche Spielerei will man da noch einbauen?

1. Ein Programm an dieser Stelle könnte mir eine Mail
      senden etc. - vielleicht habe ich ja keinen Zugriff
      auf ein error_log.

Auch einer Art von DoS ;-)

2. Ein Programm an dieser Stelle könnte den Referrer
      untersuchen und dadurch erkennen, ob ein broken link
      innerhalb meiner eigenen Domain vorliegt oder ob das
      ein mißlungener Einsprung von außen war (oder gar
      ein Tippfehler in der URL-Zeile, wobei ein leerer
      Referrer mitgeschickt würde) und dann den ausgegebe-
      nen Text darauf bedingt formulieren.

Sehr schön.
Meinst Du das interessiert irgendjemanden außer Dir (zwecks Debugging)?

Da wird gesehen "File Not Found" (oder auch in anderer Sprache, aber soviel versteht auch fast jeder). Das Wie und Warum interessiert doch keine Sau.

Sprache? Gut, das geht aber auch einfach in gzip_cnc.
(Content negotiation auf Sprache geht, da 404 in
verschiedenen Sprachen auch nur als statische
Dateien rumhängen sollten)

Dazu müßte gzip_cnc aber die komplette Negotiation mit
mehreren Endungen gleichzeitig durchführen!

Könnte ja sagen: ja und?
Tu's aber lieber mal nicht ;-)

Beispielsweise müßte es meine ErrorDocument-Datei mit
dem Namen "missing.htm.shtml.de" verstehen!
Ich will nämlich Sprachvarianten _und_ SSI in Kombi-
nation verhandeln - und ich will gleichzeitig die
Endung vor den Besuchern verstecken, die diese Datei
mal direkt ansprechen (sie ist _auch_ verlinkt).

Wozu der ganze Aufwand?
Das ist höchsten für Debuggingzwecke interessant, aber da kann man auch gzip_cnc solange ganz ausschalten. Ist billiger ;-)

Ich mag ja mit meiner Meinung ganz alleine dastehen, aber mehr als die Meldung "Datei nicht gefunden" interessiert wirklich kein Schwein!

Könnte man mal hier ein Umfrage starten ;-)

Also mehr als die Möglichkeit "'blabla.html' wurde
nicht gefunden, bitte überprüfen sie die
Schreibweise" in allen ca 5.000 Spracehn und
Dialekten der Welt anbieten zu können sehe ich
wirklich nicht.

Ich auch nur in zwei (deutsch und englisch).
Aber was würdest Du als englischsprachiger Besucher
meiner gzip_cnc-Seiten mit diesem Text hier anfangen:

http://www.schroepl.net/missing.htm

Wieder über eine misslungene 404 Seite fluchen und verschwinden.
Warum?
Einmal ist das Design genauso, wie die der anderen Seiten.
Dann: war es Dir zu peinlich ein deutliches "404" obendrüberzuschreiben?

Aber das ließe sich noch lösen, kein großes Problem.

Das ist halt _etwas_ mehr als "Überprüfen Sie die
Schreibweise für etwas, das Sie gar nicht selbst ge-
schrieben haben" (was ich übrigens bescheuert finde).

Ja, deshalb habe ich diese Formulierung auch gewählt ;-)

Schön finde ich das alles nicht (zumal ich jetzt
noch die Dokumentation entsprechend umschreiben
muß) ...
Jaja, Programmierer und Dokumentation ... ;-)))

Meine hast Du gesehen - ich Deine noch nicht ...

Quod demonstrandum erat. ;-)

Die Kommentare in meinem Paket sind schon _sehr_ ausführlich.
"Mähr gipps nich" ;-)

(Bleibt noch die Frage, was Du unter "wesentlichen
Browsern" verstehst. Aber eigentlich möcht' ich das
auch wiederum gar nicht wissen ;-)

Die neuesten Versionen von Mozilla, Opera, M$IE und
Netscape 4.

NN4 auch?
Ja gut, das sind dann wirklich alle wichtigen.

Dafür, daß dieser Handler so wenige Informationen
vom Apache kriegt, muß er ganz schön viel HTTP
machen ... gnlpfts.
Na, soviel ist es nun wirklich nicht. Ich bitte Dich! ;-)
Und außerdem: ja und? ;-)))

Es geht ja nicht darum, daß ich zu faul wäre, es zu
programmieren.
Aber je mehr HTTP-Zeug in das Programm hinein muß,
desto abschreckender wirkt die Dokumentation für po-
tentielle Benutzer, die selbst nicht programmieren
können. Und es wird auch immer schwerer für sie,
eigene Fehler bei der Installation zu finden.

Dann muß sie verborgen bleiben.
Bzw  nur dem "Expertenmodus" vorbehalten bleiben, also per Default ist das Programm mit ein paar einfachen Handgriffen einzurichten, aber wenn man möchte, kann man auch alles Mögliche einrichten und ändern.

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Meinst Du das interessiert irgendjemanden außer Dir

ja - mindestens jeden, der an dieser Stelle ebenfalls
etwas Dynamisches einsetzt.
(Ich selbst mußte das jetzt wegen gzip_cnc abschalten.)

Da wird gesehen "File Not Found" (oder auch in
anderer Sprache, aber soviel versteht auch fast
jeder).
Das Wie und Warum interessiert doch keine Sau.

Ich erzähle ja auch nichts über das "warum" - ich
bieten dem Besucher einen Weg zu seinem Ziel.

Ich mag ja mit meiner Meinung ganz alleine dastehen,
aber mehr als die Meldung "Datei nicht gefunden"
interessiert wirklich kein Schwein!

Der Besucher interessiert sich _genau_ dafür überhaupt
nicht. Er interessiert sich für das, was er auf der
nicht existierenden Seite finden wollte. Dies versuche
ich ihm zu geben.

Könnte man mal hier ein Umfrage starten ;-)

Gerne - meine Meinung kennst Du nun.

http://www.schroepl.net/missing.htm
Wieder über eine misslungene 404 Seite fluchen und verschwinden.
Warum?
Einmal ist das Design genauso, wie die der anderen Seiten.

Warum sollte es anders sein?

Dann: war es Dir zu peinlich ein deutliches "404"
obendrüberzuschreiben?

Meine Besucher sind Menschen und keine Roboter.
Was interessiert die eine HTTP-Spezifikation?

Aber das ließe sich noch lösen, kein großes Problem.

Bitte - ich bin gespannt ... ohne Apache-internen
Subrequest sehe ich keine Lösung.

Meine hast Du gesehen - ich Deine noch nicht ...
Quod demonstrandum erat. ;-)

Ich weiß im Moment noch nicht so recht, was ich mit
Deinem Paket (ohne C-Compiler) anfangen soll.

Ich habe gerade mal reingesehen: Aha, ein C-Programm.
Und was fange ich konkret damit an?

Die Kommentare in meinem Paket sind schon _sehr_
ausführlich.
"Mähr gipps nich" ;-)

Für welche Zielgruppe ist das denn in dieser Form
gedacht, wenn schon nicht mal ich das begreife?

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Meinst Du das interessiert irgendjemanden außer Dir

ja - mindestens jeden, der an dieser Stelle ebenfalls
etwas Dynamisches einsetzt.

Der Besucher setzt nichts ein, der guckt nur mehr oder weniger verdattert. ;-)

(Ich selbst mußte das jetzt wegen gzip_cnc abschalten.)

Warum?
Du hast den UA, warum fragst Du den nicht nach der Sprache und hältst die eigentlichen 404 Dokumente statisch?

Ich mag ja mit meiner Meinung ganz alleine dastehen,
aber mehr als die Meldung "Datei nicht gefunden"
interessiert wirklich kein Schwein!

Der Besucher interessiert sich _genau_ dafür überhaupt
nicht. Er interessiert sich für das, was er auf der
nicht existierenden Seite finden wollte. Dies versuche
ich ihm zu geben.

Ds tust Du nicht, Du bietest nur die üblichen Alternativen an. Das einzige zusätzliche ist eine Suchmaschinenmaske und das geht auch in einer statischen Datei.
Oder habe ich da irgendetwas übersehen?

Könnte man mal hier ein Umfrage starten ;-)

Gerne - meine Meinung kennst Du nun.

Das wären dann zwei und die auch noch recht gegensätzlich.
Nicht sehr repräsentativ ,-)
Also versuch ich es mal.

http://www.schroepl.net/missing.htm
Wieder über eine misslungene 404 Seite fluchen und verschwinden.
Warum?
Einmal ist das Design genauso, wie die der anderen Seiten.

Warum sollte es anders sein?

Das es eine Fehlermeldung ist und welche sollte eindeutig erkennbar sein.

Das mit dem anderem Design bezog sich aber auch mehr auf den Besucher, der die angebotene Sprache nicht versteht, also auf Deine eigentliche Frage.

Dann: war es Dir zu peinlich ein deutliches "404"
obendrüberzuschreiben?

Meine Besucher sind Menschen und keine Roboter.
Was interessiert die eine HTTP-Spezifikation?

Wenn auch nichts bekannt ist, 404 ist. Weiß zwar wahrscheinlich kaum einer, woher das kommt, aber das es "Datei nicht gefunden" bedeutet.

Aber das ließe sich noch lösen, kein großes Problem.

Bitte - ich bin gespannt ... ohne Apache-internen
Subrequest sehe ich keine Lösung.

Du willst Deine Fehlermeldung in mehreren Sprachen anbieten. Die Entscheidung, welche das sein soll, kannst Du eigentlich nur über den UA lösen, oder der Besucher hat sie einmal gewählt. Das erste ist kein Problem, das zweite könnte vielleicht eines werden, je nach Implementation.

Meine hast Du gesehen - ich Deine noch nicht ...
Quod demonstrandum erat. ;-)

Ich weiß im Moment noch nicht so recht, was ich mit
Deinem Paket (ohne C-Compiler) anfangen soll.

Welches?
Wenn Du meine Version von gzip_cncc meinst, das ist erst mal nur für Entwickler. Da kommen dann nachher auch Binaries wenn alles ausreichend getestet ist.

Das gzip_stream Teil ist erst ein Entwurf. Aufgrund meines teilweise sehr veralteten Systems dürften meine Binaries nirgendwo anders laufen. Aber ich kann sie ja mal statisch linken. (Nur die libc, oder auch die libz?)

Ich habe gerade mal reingesehen: Aha, ein C-Programm.
Und was fange ich konkret damit an?

Gucken, staunen, bauen, benutzen ;-)
(Du hast zwei Verschiedene bekommen, ich weiß also nicht, auf welches Du Dich beziehst)

Die Kommentare in meinem Paket sind schon _sehr_
ausführlich.
"Mähr gipps nich" ;-)

Für welche Zielgruppe ist das denn in dieser Form
gedacht, wenn schon nicht mal ich das begreife?

Erstmal nur für Entwickler. Da hatte ich Dich eigentlich auch zugezählt. War das verkehrt? (Ich habe keine besonderen Tricks und Kniffe benutzt. Grundkenntnisse in C und Präprozessordirektiven sollten reichen)

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hallo,

Na, Mimetype immer noch fest? ;-)
Ja, weil ich außer HTML keinen Bedarf sehe.
Mmh...
Eigentlich für fast alle text/*, oder?
Wer liefert so etwas in nennenswerten Stückzahlen aus?
es gibt:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/
sowie noch einige hiervon:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/
und etwas:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/
nicht zu vergessen eine Prise:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/model/
Eine Menge. Alles nicht nennenswert?

Alles nicht nennenswerte Anteile meines Web-Traffic.
Eher alles zusammen genau Null Prozent.

Naja, bei über 300 Mio Websites ausgerechnet Deine zum Vorbild zu nehmen ... ;-)

Bei "Application" würde ich Komprimierung noch am
ehesten verstehen (das sind wahrscheinlich große
Dateien und vermutlich auch gut komprimierbar), aber
die werden nur in wenigen Fällen dynamisch im Browser
interpretiert, können also auch geZIPt werden.

Ja, da ist einiges, vor allem aus dem XML Bereich, drin.

Und ein paar Anwendungen verwenden ja auch wieder
ihre eigenen Archiv-Formate (z. B. *.jar").

Nein, das ist nichts eigenes, das ist auch ZIP ;-)

BTW: man versicherte mir von anderer Stelle, das
gmtime() von Perl richtig funktioniert, also stets
auf GMT umrechnet,

Dachte ich eigentlich auch - fein.

Und warum funktioniert das bei mir nicht? ;-)

Würde sowieso eine Weltzeit anempfehlen.
In Zeiten von modernster Kommunikationsmitteln,
globaler Märkte und Concorde sind Zeitzonen doch eh
ein verstaubtes Relikt aus längst vergang'nen Tagen,
oder? ;-)

Wenn Du dann bitte auch noch das Beleuchtungsproblem
gleich mit lösen würdest ... ?

Beleuchtet wird, wenn's dunkel ist.
Wo liegt das Problem?

Zu festgefahren in den alten Traditionen, was? ;-)

Also: Ist implementiert in 1.08.
Überzeugt, oder nur genervt? ;-)

Eigentlich überzeugt. Ich fürchte nur, das Problem ist
gar nicht lösbar.

Na, doch, das glaube ich schon.
Aber ich stehe gerade vor einem unlösbarem Problem (nicht hier):
Wie kann man prüfen, ob für eine zukünftige Operation genügend Speicher vorhanden sein wird?
Ist auf einem Multitaskingsystem bei zwei verschiedenen Prozessen einfach nicht lösbar.

Ich habe das folgendermaßen gelöst:
Wenn nix gefunden wurde && eine eigene 404-Datei
durch einen kompletten und gültigen Pfad definiert
ist, sendet er den passenden Header, liest die Datei
aus und hängt sie dran.

Genau das kann ich aber nicht.

Denn damit schließe ich alle 404-handler, die über URLs
arbeiten _müssen_ (weil sie selbst dynamische Ausgaben
erzeugen), aus.

404 ist "File not found"
Da gibt es nix zu basteln.

Nichts gegen eine nett gemachte 404 Seite, aber diese Arbeitskraft sollte eher in die Vermeidung gesteckt werden, nicht in die Befriedigung des Spieltriebes.

Äh, und wie greifst Du dann auf den Inhalt der
dynamisch erzeugten Seite zu?
Wollte ich eigentlich gar nicht, sondern nur einen
Stream verarbeiten.
Ich greife also nicht auf die Seite zu, sondern die
Seite auf mich.
Das könnte z.B. via HTTP-POST funktionieren.

Ich habe ungefähr kein Wort davon verstanden ...

Na, wenn es nur "ungefähr" ist, geht's ja noch ;-)

Ich versuche mal ein kleines Beispiel zu basteln.
Vielleicht sogar heut' noch ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Christoph,

Naja, bei über 300 Mio Websites ausgerechnet Deine
zum Vorbild zu nehmen ... ;-)

welche denn sonst?
Über andere habe ich keine so genauen Zahlen ...

die werden nur in wenigen Fällen dynamisch im Browser
interpretiert, können also auch geZIPt werden.
Ja, da ist einiges, vor allem aus dem XML Bereich, drin.

Fein - dann sind es ja schon zwei MIME-Typen. ;-)

Und ein paar Anwendungen verwenden ja auch wieder
ihre eigenen Archiv-Formate (z. B. *.jar").
Nein, das ist nichts eigenes, das ist auch ZIP ;-)

Doch, das ist etwas Eigenes, das mit Content-Encoding
nichts zu tun hat - genau wie GIF oder PNG oder ...

Alle diese Sonderlösungen gäbe es womöglich gar nicht,
wenn HTTP Content Encoding bereits in allen Webservern
implementiert wäre.

BTW: man versicherte mir von anderer Stelle, das
gmtime() von Perl richtig funktioniert, also stets
auf GMT umrechnet,
Dachte ich eigentlich auch - fein.
Und warum funktioniert das bei mir nicht? ;-)

Keine Ahnung. Mach doch mal einen Forum-Thread daraus
und beschreibe die Symptome ... ;-)

Würde sowieso eine Weltzeit anempfehlen.
Wenn Du dann bitte auch noch das
Beleuchtungsproblem gleich mit lösen würdest ... ?
Beleuchtet wird, wenn's dunkel ist.
Wo liegt das Problem?
Zu festgefahren in den alten Traditionen, was? ;-)

Falls Du die Durchführeung der Umerziehung der gesam-
ten Weltbevölkerung gleich mit übernehmen möchtest,
bist Du bis auf weiteres beschäftigt, fürchte ich.

Also: Ist implementiert in 1.08.
Überzeugt, oder nur genervt? ;-)

Aber ich stehe gerade vor einem unlösbarem Problem
(nicht hier):
Wie kann man prüfen, ob für eine zukünftige
Operation genügend Speicher vorhanden sein wird?
Ist auf einem Multitaskingsystem bei zwei
verschiedenen Prozessen einfach nicht lösbar.

Klingt irgendwie nach Philosophenproblem ... mehr
als versuchsweise allozieren und deadlocks behandeln
fällt mir auf Anhieb auch nicht ein.

404 ist "File not found"
Da gibt es nix zu basteln.

Das ist ungefähr so repräsentativ wie meine MIME-
Verteilung. ;-)

Nichts gegen eine nett gemachte 404 Seite, aber
diese Arbeitskraft sollte eher in die Vermeidung
gesteckt werden, nicht in die Befriedigung des
Spieltriebes.

Ach ja, wie schaffst Du denn die Existenz sämtlicher
Bookmarks und veralteten Kopien von Seiten auf fremden
Servern ab? Und sag nicht, es sollten alle URLs in
Ewigkeit stabil bleiben ... das habe ich beim Einsatz
von Fremdsoftware leider nicht unter Kontrolle.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

die werden nur in wenigen Fällen dynamisch im Browser
interpretiert, können also auch geZIPt werden.
Ja, da ist einiges, vor allem aus dem XML Bereich, drin.

Fein - dann sind es ja schon zwei MIME-Typen. ;-)

Also mehr als eine. Damit fängt der Ärger dann an.
Oder besser gesagt: es ist egal, ob man für 2 oder 200 verschieden Mimtypen ein Auswahlverfahren schafft ;-)

Und ein paar Anwendungen verwenden ja auch wieder
ihre eigenen Archiv-Formate (z. B. *.jar").
Nein, das ist nichts eigenes, das ist auch ZIP ;-)

Doch, das ist etwas Eigenes, das mit Content-Encoding
nichts zu tun hat - genau wie GIF oder PNG oder ...

Nein, ich meinte JAR selber, nicht den Mimetype.

Alle diese Sonderlösungen gäbe es womöglich gar nicht,
wenn HTTP Content Encoding bereits in allen Webservern
implementiert wäre.

Oh, ja! *sigh*

BTW: man versicherte mir von anderer Stelle, das
gmtime() von Perl richtig funktioniert, also stets
auf GMT umrechnet,
Dachte ich eigentlich auch - fein.
Und warum funktioniert das bei mir nicht? ;-)

Keine Ahnung. Mach doch mal einen Forum-Thread daraus
und beschreibe die Symptome ... ;-)

Nein, besser nicht.
Ich habe hier ein System, das mitunter Fehler hat, die nirgendwo anders nachzuvollziehen sind.
Noch schlimmer: geht manchmal auch andersrum! ;-)

Ja, wenn ich mir mal 'ne neue Maschine kaufe ... ;-)

Würde sowieso eine Weltzeit anempfehlen.
Wenn Du dann bitte auch noch das
Beleuchtungsproblem gleich mit lösen würdest ... ?
Beleuchtet wird, wenn's dunkel ist.
Wo liegt das Problem?
Zu festgefahren in den alten Traditionen, was? ;-)

Falls Du die Durchführeung der Umerziehung der gesam-
ten Weltbevölkerung gleich mit übernehmen möchtest,
bist Du bis auf weiteres beschäftigt, fürchte ich.

Das geschieht von gan alleine, wenn mal umgestellt wird.
Mit dem Euro funktioniert's ja auch! >;->

Also: Ist implementiert in 1.08.
Überzeugt, oder nur genervt? ;-)

Aber ich stehe gerade vor einem unlösbarem Problem
(nicht hier):
Wie kann man prüfen, ob für eine zukünftige
Operation genügend Speicher vorhanden sein wird?
Ist auf einem Multitaskingsystem bei zwei
verschiedenen Prozessen einfach nicht lösbar.

Klingt irgendwie nach Philosophenproblem ... mehr
als versuchsweise allozieren und deadlocks behandeln
fällt mir auf Anhieb auch nicht ein.

Nein, es geht einfach nicht sicher. Ist halt eine statistische Frage, muß man sich eben drauf einstellen.
Nur, mach das mal jemandem klar!

404 ist "File not found"
Da gibt es nix zu basteln.

Das ist ungefähr so repräsentativ wie meine MIME-
Verteilung. ;-)

Jau! ;-)

Nichts gegen eine nett gemachte 404 Seite, aber
diese Arbeitskraft sollte eher in die Vermeidung
gesteckt werden, nicht in die Befriedigung des
Spieltriebes.

Ach ja, wie schaffst Du denn die Existenz sämtlicher
Bookmarks und veralteten Kopien von Seiten auf fremden
Servern ab? Und sag nicht, es sollten alle URLs in
Ewigkeit stabil bleiben ... das habe ich beim Einsatz
von Fremdsoftware leider nicht unter Kontrolle.

Warum denn? Die kriegen auf Nachfrage einen 404 und fertig.

Aber das ist wohl auch eine Geschmacksfrage, ich halte sowas nunmal für überflüssige Spielerei.

so short

Christoph Zurnieden

[Michael Schröpl]

Hi,

Fein - dann sind es ja schon zwei MIME-Typen. ;-)
Also mehr als eine. Damit fängt der Ärger dann an.
Oder besser gesagt: es ist egal, ob man für 2 oder 200 verschieden Mimtypen ein Auswahlverfahren schafft ;-)

Das gibt es ja (über die Environment-Variablen).

Und was den Komfort angeht, ist das durchaus ein
Unterschied, ob der Anwender zwei oder 200 MIME-Typen
selbst definieren muß.

Mit dem Euro funktioniert's ja auch! >;->

Das sagst Du dem richtigen (nämlich einem Angestellten
eines Finanzdienstleisters).

Nichts gegen eine nett gemachte 404 Seite, aber
diese Arbeitskraft sollte eher in die Vermeidung
gesteckt werden, nicht in die Befriedigung des
Spieltriebes.

Ach ja, wie schaffst Du denn die Existenz sämtlicher
Bookmarks und veralteten Kopien von Seiten auf fremden
Servern ab? Und sag nicht, es sollten alle URLs in
Ewigkeit stabil bleiben ... das habe ich beim Einsatz
von Fremdsoftware leider nicht unter Kontrolle.

Warum denn? Die kriegen auf Nachfrage einen 404 und fertig.
Aber das ist wohl auch eine Geschmacksfrage, ich halte sowas nunmal für überflüssige Spielerei.

Ich behandele Kunden weniger uneinsichtig.

Bedenke, daß die Leute, die auf unserer Serverfarm
arbeiten, viel Geld dafür bezahlen und daß die Alter-
native _dafür_ nicht "einen Mausklick entfernt" ist.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Zurnieden]

Hallo,

Fein - dann sind es ja schon zwei MIME-Typen. ;-)
Also mehr als eine. Damit fängt der Ärger dann an.
Oder besser gesagt: es ist egal, ob man für 2 oder 200 verschieden Mimtypen ein Auswahlverfahren schafft ;-)

Das gibt es ja (über die Environment-Variablen).

Die stehen leider nicht für alle Apache Versionen vollständig zur Verfügung.
Das war ja die Ursache des Problems.

Und was den Komfort angeht, ist das durchaus ein
Unterschied, ob der Anwender zwei oder 200 MIME-Typen
selbst definieren muß.

Muß er ja nicht, man kann auch einfach alle von IANA + die schon gängigen aber noch nicht richtig registrierten (wie z.B. x-bzip2) implementieren.
Ändert nichts wesentliches an der Laufzeit, würde nur das Binary um ca 5kb vergrößern.

Mit dem Euro funktioniert's ja auch! >;->

Das sagst Du dem richtigen (nämlich einem Angestellten
eines Finanzdienstleisters).

Deshalb auch das Sarkasmus-Grinsemännchen _mit_ Hörnern dahinter ;-)

Nichts gegen eine nett gemachte 404 Seite, aber
diese Arbeitskraft sollte eher in die Vermeidung
gesteckt werden, nicht in die Befriedigung des
Spieltriebes.

Ach ja, wie schaffst Du denn die Existenz sämtlicher
Bookmarks und veralteten Kopien von Seiten auf fremden
Servern ab? Und sag nicht, es sollten alle URLs in
Ewigkeit stabil bleiben ... das habe ich beim Einsatz
von Fremdsoftware leider nicht unter Kontrolle.

Warum denn? Die kriegen auf Nachfrage einen 404 und fertig.
Aber das ist wohl auch eine Geschmacksfrage, ich halte sowas nunmal für überflüssige Spielerei.

Ich behandele Kunden weniger uneinsichtig.

Hey, ich bin Deutscher, man erwartet von mir, daß ich die Kunden wie den letzten Dreck behandele! >;->

Jaja, jetzt lebe ich schon mit Unterbrechungen fast 40 Jahre hier in D (Hups, jetzt habe ich mein Alter verraten ;-) und die Unterbrechungen zeigten mir jedesmal deutlich, wie schlimm es hierzulande um den Kundenservice steht. *sigh*

Aber wenn der Kunde Funktionen auf der 404-Seite haben will, die sich nur dynamisch erreichen lassen und sich nicht von Gegenteil überzeugen läßt, dann soll er die natürlich haben. Mit besonders freundlichem Grinsen und einem "Danke für ihren Auftrag" noch dabei.

Bedenke, daß die Leute, die auf unserer Serverfarm
arbeiten, viel Geld dafür bezahlen und daß die Alter-
native _dafür_ nicht "einen Mausklick entfernt" ist.

Die Alternativen kannst Du doch trotzdem einbauen!
Ich verstehe Dein Problem immer noch nicht.

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hallo,

Da ein rename() Fehler nicht abgefangen wird, kann
die Datei weiterexistieren.
Wenn die PID Zählung am Ende angekommen ist, wird
wieder am Anfang begonnen (nicht ganz und nur unter
den mir bekannten Unices, aber das ist der Großteil
der Server Betriebsysteme)
Das kann bei Großbetrieben durchaus häufiger
auftauchen.

Aber wie lange dauert es zwischen zwei Prozeß-Instanzen
mit derselben PID? Länger, als das Gzippen einer Datei
dauert. Die übrig bleibende Cache-Datei tut nicht weh

• die wird beim nächsten Mal einfach überschrieben.

Ja, das fiel mir auch auf, just als ich das "Danke" vom Forum erhalten hatte ;-)

Es dürfen nur nicht _gleichzeitig_ zwei Prozesse mit
derselben PID laufen, weil die in dieselbe Datei
schreiben und ein korruptes Ergebnis erzeugen würden.

Wenn gleichzeitig zwei Prozesse mit derselben PID laufen, hast Du andere Probleme als ein korruptes Ergebnis ;-)

Die zlib erzeugt übrigens eine Checksum. Warum die
nicht nehmen?

Weil ich dann zuerst im Speicher komprimieren und
danach in die Datei schreiben müßte. Ich müßte also
die Daten lokal auch noch einmal puffern - und dazu
im schlimmsten Fall mit backticks die Ausgabe von
/bin/gzip -c auffangen, grusel ...

Ach hör doch auf! Als, ob Dir vor sowas gruseln würde! ;-)))

Aber ich habe mir die C-Portierung vorgenommen, und da die Sache einmal durchgespielt. Nützt auch nichts.
Um vom getpid() wegzukommen kann man nur reguläres Filelocking betreiben.
Das ist Aufwand in zweifacher Hinsicht: einmal die Implementierung selber und zum anderem der Overhead bei der Ausführung.

Nein, um getpid() ist leider nicht einfach genug herumzukommen.

Reines ANSI-C ist demnach zu aufwendig. (Was mich ein wenig wurmt) aber zumindest der POSIX Standard läßt sich einhalten, wenn man ihn nicht voll ausnutzt.

Ich hatte eher den Umstand im Auge, das evt
derselbe Datei_name_ mehrfach in den Cache
geschickt wird ;-)
Ich auch (falls derselbe Dateiname über ent-
sprechende Alias-Mappings auf mehrer URLs
abgebildet wird, haben wir halt ein bißchen
Redundanz im Cache).
Ich meinte den umgekehrten Fall. Das also mehrere
Dateien den gleichen Namen haben könnten.

Wie soll das gehen? Innerhalb eines Dateisystems, das
ich kenne, erscheint mir das unmöglich.

Nein, nicht im Dateisystem ;-)

Ich kenne mich allerdings in den Pfadtranslations-
mechanismen des Apachen nicht gut genug aus.

Die Dokumentationen zu gzip_cnc und mod_gzip sind
beide zweisprachig und werden via Content Negotiation
über mehrdeutige URLs angesprochen - das ist wohl das
Szenario, welches Du meinst: Mehrdeutige Request-URLs.

Ja, genau. Danke.
Irgendwas war da doch ncoh, soviel wußte ich noch ;-)

gzip_cnc 1.04 wurde damit noch nicht fertig (und
gzip_cncc 0.2 meines Wissens auch nicht). gzip_cnc
1.05 dagegen macht das richtig (ich brauche es ja
für meine eigenen Seiten).

Es funktioniert so:

PATH_INFO ist der angeforderte URL _vor_ Negotiation;
PATH_TRANSLATION ist der vom Apache übersetzte Datei-
name _nach_ Negotiation. Dort sind beispielsweise auch
Directory-Zugriffe schon nach "index.html" etc über-
setzt - gzip_cnc bekommt immer einen eindeutigen
Dateinamen, allerdings nur in PATH_TRANSLATED, nicht
in PATH_INFO.

Hat er auch geändert. Zumindest steht bei mir getenv("PATH_TRANSLATED")

gzip_cnc 1.04 nahm noch komplett PATH_INFO und adres-
sierte dann in der Tat fälschlicherweise sämtliche
negotiated-Varianten eines URL über dieselbe Cache-
Datei, lieferte also zufällige und unbrauchbare Sprach-
Varianten aus (der erste Zugriff erzeugt die Cache-
Version, alle nachfolgenden Zugriffe glauben ihren
Inhalt).

gzip_cnc 1.05 nimmt, um nun den Pfadnamen der zuge-
hörigen Cache-Datei zu berechnen,
a) den Verzeichnispfad aus PATH_INFO, aber
b) den Dateinamen aus PATH_TRANSLATED.
Nun entstehen für index.htm.de und index.htm.en zwei
verschiedene Cache-Dateien, die beide für den URL
index.htm ausgeliefert werden könnten.

Nein, das tut gzip_cncc noch nicht.
Betonung liegt auf _noch_ nicht ;-)

(In der stillen Hoffnung, daß ich das jetzt auch richtig verstanden habe)

Wer baut eigentlich PATH_INFO zusammen?
Verdammt, ich muß mir doch mal ein vernünftiges cgi-bin zusammenschustern ;-)

(So ganz ohne ist das irgendwie schlecht mit Testen, geht zwar auch, aber ... ;-)

Ja, insbesondere für die Leute, die einem das
automatisierte Runterladen schwer machen, in dem
sie jede "Wurzeldatei" in jedem Unterverzeichnis
als "index.html" bezeichnen.
*grrr*
;-)

Wie meinen der Herr?

Nichts, nichts, Herr Kollege. ;-)
Du warst eh nicht gemeint. Habe nur mal meinem Unmut etwas Luft gemacht.
Wollte mir einige Teile einer Dokumentation runterladen und mußte feststellen, das die anstatt über verschiedene Dateinamen und einer anständigen Verzeichnisstruktur, statt der verschiedenen Dateinamen verschiedene Verzeichnisse genommen hatten und überall war eine Datei drin: index.htm.

Wenn man dann aus dem Inhaltsverzeichnis ein paar der Links hinter ein wget packt und dann nicht drauf achtet ...
Ja, ich weiß, C&P hat schon so manches Opfer gefordert ;-)

PS: sind meine Mails angekommen?

Äh ... hier privat nicht.

Ja, was man macht, macht man verkehrt *sigh* ;-)

(Ins Büro komme ich erst wieder nach dem Halbfinale.)

Was für ein Halbfinale?

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Christoph,

Wer baut eigentlich PATH_INFO zusammen?

Offenbar die Apache-API beim Aufruf eines handlers:

http://httpd.apache.org/dev/API.html#req_tour

Wollte mir einige Teile einer Dokumentation
runterladen und mußte feststellen, das die anstatt
über verschiedene Dateinamen und einer anständigen
Verzeichnisstruktur, statt der verschiedenen
Dateinamen verschiedene Verzeichnisse genommen
hatten und überall war eine Datei drin: index.htm.

Das mache ich manchmal auch - z. B. wenn jedes dieser
Dokumente seine eigenen Graphiken besitzt.

(Ins Büro komme ich erst wieder nach dem Halbfinale.)
Was für ein Halbfinale?

Na, welches Halbfinale wohl? Das zweite natürlich. ;-)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Thomas J.S.]

hallo Michael,

hat inzwischen die Versionsnummer 1.05 ... und heißt
gzip_cnc.

ich habe jetzt ein wenig im therad hineingelesen, ohne viel davon zu verstehen; aber mir stellt sich jetzt eine frage:

wie sicher bzw. stabil ist die version 1.05?
ich habe sie mir nämlich an meinem server installiert und nun würde ich gerne wissen, ob ich mit probleme rechnen sollte ode nicht.

Verständlichkeit der
Formulierungen, Probleme beim Ausprobieren ... immer
her damit.

ich hatte eine ganze weile gebraucht bis ich verstanden haben was ich unter "Festlegung des Wurzelverzeichnisses für den Cache-Baum" mit "innerhalb des URL-Baums" und "außerhalb des URL-Baums" meint.
das ist deshalb verwirrend weil ihr mal über document-root spricht, aber fast immer der domain-root gefragt ist und ein URL-Baum als begriff ziemlich wenig eindeutig ist.

das zweite problem hatte ich beim "Festlegung der gzip_cnc-eigenen Protokolldatei" es steht nirgednwo dass der pfad vom domain-root ausgehen angegeben werden muss und es wird auch nicht gesagt, dass man die protokolldatei erst selbst tatsächlich anlegen soll (zumindest wurde sie bei mir nicht automatisch erstellt)

vielleicht könntet ihr beispiele in den erklärungen geben.

ansonsten war alles klar.

vielen dank für eure arbeit und
grüße
thomas

ps:was meinst du mit "allen browser" ??

.: Falls mir beispielsweise jemand erklären könnte,

was ich in meinem CSS verkehrt mache ... die
      Navigation sollte eigentlich in allen Browsern
      so aussehen wie im M$IE, also mit gleich breiten
      hover-Balken ...

[Michael Schröpl]

Hi Thomas,

wie sicher bzw. stabil ist die Version 1.05?

sie läuft auf www.schroepl.net produktiv:

http://www.schroepl.net/cgi-bin/http_trace.pl?url=http%3A%2F%2Fwww.schroepl.net%2Fprojekte%2Fgzip_cnc%2F&method=HEAD&version=HTTP%2F1.0

, ohne irgendwelche Einträge im error_log zu
verursachen.

Das galt übrigens auch für alle vorherigen Versionen.
Schon die 1.00 (2002-05-12) habe ich dort verwendet

• damals noch mit temporärer Kopie der Original-Datei
  _vor_ dem Komprimieren per system("cp") und mit der
  Erzeugung von Cache-Pfaden mit system("mkdir -p") ...
  Christian hat in meinem Code kräftig aufgeräumt.

Ich lade nur Versionen von gzip_cnc hoch, die zuvor

• sowohl auf meinem Win98-PC (dort mit Compress::Zlib)
• als auch für schroepl.net  (dort mit /bin/gzip)
  erfolgreich getestet wurden und die ich auch selbst
  produktiv einsetze.

ich habe sie mir nämlich an meinem server
installiert und nun würde ich gerne wissen,
ob ich mit probleme rechnen sollte ode nicht.

Mit Problemen sollte man immer rechnen. ;-)

Aber wenn Du meine Homepage erreichen kannst, dann
sollte Deine ebenfalls eine gute Chance haben.

Im Übrigen gilt natürlich
http://www.schroepl.net/projekte/gzip_cnc/install.htm#test

• ein Fingerfehler während der Installation ist schnell
  gemacht ... das passiert mir durchaus auch selbst.

ich hatte eine ganze weile gebraucht bis ich
verstanden haben was ich unter "Festlegung des
Wurzelverzeichnisses für den Cache-Baum" mit
"innerhalb des URL-Baums" und "außerhalb des URL-
Baums" meint.
das ist deshalb verwirrend weil ihr mal über
document-root spricht, aber fast immer der domain-
root gefragt ist und ein URL-Baum als begriff
ziemlich wenig eindeutig ist.

In der Apache-Terminologie gibt es keine "Domain-Root".
Auch ein Virtual Host hat eine DocumentRoot:
http://httpd.apache.org/docs/mod/core.html#documentroot

gzip_cnc ist es aber egal, ob es für einen Virtual Host
läuft oder für einen ganzen Server - der kennt diese
Begriffe nicht.
Die DOCUMENT_ROOT ist halt die einzige Environment-
Variable der CGI-Schnittstelle, die mir einen halbwegs
sinnvollen Defaultwert für die Pfade gibt - ich hatte
die Hoffnung, daß gzip_cnc selbst ohne jede Änderung
im Quelltext irgendwie funktionieren kann.
Besser ist es in jedem Fall, die beschriebenen Stellen
so anzupassen, daß man mit den Ergebnissen glücklich
wird - gzip_cnc braucht keine Protokolldatei, aber der
Benutzer wird eine haben wollen, um zu verstehen, was
passiert.

Und Du kannst sowohl den Cache-Baum als auch die Pro-
tokolldatei hinlegen, wo immer Du willst - Hauptsache,
die Benutzerkennung, unter der gzip_cnc läuft, hat dort
Schreibrecht. Das ist wie bei jedem anderen CGI-Skript.
Du _kannst_ beides auch in den URL-Raum legen - ich
halte das bloß nicht für übersichtlich, statische und
dynamische Dateien miteinander zu mischen.

das zweite problem hatte ich beim "Festlegung der
gzip_cnc-eigenen Protokolldatei" es steht nirgednwo
dass der pfad vom domain-root ausgehen angegeben
werden muss

Muß er auch gar nicht.
gzip_cnc arbeitet nur mit absoluten Pfaden.

Die Funktion "terminate" macht die Log-Datei mit

if (open (LOG, ">>$logfile_path"))

auf - da ist nichts mit "relativ zu irgendwas".

und es wird auch nicht gesagt, dass man die
protokolldatei erst selbst tatsächlich anlegen
soll

"soll" und muß man auch nicht.
">>" legt die Datei an, falls sie nicht existiert.

(zumindest wurde sie bei mir nicht automatisch
erstellt)

Wo hast Du sie erzeugen wollen?
Hast Du dort Schreibrecht?
Steht in Deinem error_log irgendwas von
  "failed to open log file" und
  "fopen: Permission denied" ?

Wenn Du irrtümlich einen relativen Pfad verwendest,
wo ein absoluter Pfad notwendig ist (nämlich überall),
dann kann es gut sein, daß dieser Pfad so gar nicht
existiert.
gzip_cnc versucht beispielsweise nicht, auf dem Weg
zum Logfile-Pfad fehlende Verzeichnisse anzulegen -
es könnte dies tun, aber falls es notwendig wäre,
würde das mit hoher Wahrscheinlichkeit an einem Miß-
verständnis liegen und dann der angegebene Pfad wegen
fehlender Berechtigungen (ab UNIX-Filesystem-Root)
ohnehin unbrauchbar sein.

Und in diesem Fall kann gzip_cnc nichts tun:

(if we can't open the file, where should we write the message to?)

Ich würde Dir ja gerne eine Fehlermeldung ausgeben -
ich weiß nur nicht, wohin. In das ausgegebene Dokument
im Browser kann ich sie ja schlecht schreiben - denn
das sollte ja i.d.R. komprimiert sein ... und wenn es
tatsächlich einen Perl-Laufzeitfehler gibt, dann
steht er ohnehin im error_log (bei mir wäre das der
Fall).

vielleicht könntet ihr beispiele in den erklärungen
geben.

Wie soll ich das tun, ohne die Verzeichnisstruktur
Deines Servers zu kennen?
Wüßte ich, daß jeder Benutzer seine CGI-Skripte unter
einer eigenen Benutzerkennung ausgeführt bekommt,
dann könnte ich versuchen, das Heimatverzeichnis
dieser Benutzerkennung zu verwenden - dies aber ist
auch wieder nur dann der Fall, wenn der Provider
suexec oder etwas Ähnliches einsetzt ...

Pfade sind immer etwas sehr Individuelles bei einer
Installation - ich will eben gerade _nicht_ irgend-
welche Werte wie /tmp vorgeben, die dann von den Be-
nutzern blind abgeschrieben werden und genau _nicht_
funktionieren, wenn zwei Benutzer gzip_cnc auf dem-
selben Server einsetzen.

Auf meinem Webspace liegen die Dateien von URL-Raum
und sonstigen Kram beispielsweise ziemlich weit von-
einander entfernt:

• URL-Räume liegen in /www/<domainname>,
• sonstiges Zeug liegt in /home/<domainname>.
  Folglich liegen bei mir auch der Cachebaum und alle
  Log-Dateien in /home/<domainname> - also eben gerade
  _nicht_ relativ zu DOCUMENT_ROOT.
  Das wird aber bei den meisten Anwendern wieder völlig
  anders sein - oft ist der URL-Raum ein Unterverzeichnis
  des FTP-Einwahlpunktes oder was auch immer.
  Und manchmal haben die Webspaces überhaupt keinen
  Bereich außerhalb des URL-Raums ...

ansonsten war alles klar.

Fein. Ich bin gespannt auf die Komprimierungswirkung ...

(Auswertung 'meiner' Zugriffe seit 6. Juni, der letzten
Logfile-Format-Änderung:
http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc_log_eval/)

ps:was meinst du mit "allen browser" ??
      was ich in meinem CSS verkehrt mache ... die
      Navigation sollte eigentlich in allen Browsern
      so aussehen wie im M$IE, also mit gleich
      breiten hover-Balken ...

Zu dem Zeitpunkt, als ich das gepostet hatte, war noch
kein "display:block" drin, wenn ich das richtig in Er-
innerung habe - der M$IE wertet wohl allein schon die
width-Angabe von dem, was in der damaligen Version um
die Links herum existierte (<p>?), so aus, wie Mozilla
und Opera das, was Du jetzt im Quelltext vorfindest.
Das ist inzwischen behoben worden.

Viel Erfolg beim Ausliefern komprimierter Seiten
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Thomas J.S.]

hallo Michael,

wie sicher bzw. stabil ist die Version 1.05?

sie läuft auf www.schroepl.net produktiv:
, ohne irgendwelche Einträge im error_log zu
verursachen.
Mit Problemen sollte man immer rechnen. ;-)

ich meinte aber auch fragen wie CPU-usage, denn ich möchte ja nicht, dass mich mein provider wegen CPU-"overusage" mahnt.

Aber wenn Du meine Homepage erreichen kannst, dann
sollte Deine ebenfalls eine gute Chance haben.

dann kann und konnte ich, sowohl deine als auch meine.

In der Apache-Terminologie gibt es keine "Domain-Root".
Auch ein Virtual Host hat eine DocumentRoot:
http://httpd.apache.org/docs/mod/core.html#documentroot

ihr wolltet doch die formulierungen auch für laien verständlich machen (?)

gehen wir also davon aus:
/usr/local/apache/htdocs

das ist also der document-root ... schön, aber! geht man mit FTP auf seinem server finden man in etwa sowas vor:
/htdocs
/logs
/ftp

das ist ebenfalls ein URL-Baum und man befindet sich im domain-root und das hat nichts mit der apache terminologie zu tun. und einen laien wird die apache terminologie wohl wenig interessieren.

gzip_cnc ist es aber egal, ob es für einen Virtual Host
läuft oder für einen ganzen Server - der kennt diese
Begriffe nicht.
Die DOCUMENT_ROOT ist halt die einzige Environment-
Variable der CGI-Schnittstelle, die mir einen halbwegs
sinnvollen Defaultwert für die Pfade gibt

das ist auch ok, aber das anlegen des cache-verzeichnisses liegt nicht allein am script. man muss das verzeichniss selbst anlegen (also per FTP) und erst dann diese im script angeben.

• gzip_cnc braucht keine Protokolldatei, aber der
  Benutzer wird eine haben wollen, um zu verstehen, was
  passiert.

eben! ;-)

Und Du kannst sowohl den Cache-Baum als auch die Pro-
tokolldatei hinlegen, wo immer Du willst -

das war mir schon klar, nur eure erklärungen dazu waren etwas verwirrend.

gzip_cnc arbeitet nur mit absoluten Pfaden.

das müsst ihr aber wo auch dann sagen!

und es wird auch nicht gesagt, dass man die
protokolldatei erst selbst tatsächlich anlegen
soll

"soll" und muß man auch nicht.
">>" legt die Datei an, falls sie nicht existiert.

(zumindest wurde sie bei mir nicht automatisch
erstellt)

Wo hast Du sie erzeugen wollen?
Hast Du dort Schreibrecht?
Steht in Deinem error_log irgendwas von
  "failed to open log file" und
  "fopen: Permission denied" ?

natürlich habe ich alle rechte , im error log steht nichts.
aber es wurde erst dann protokolliert als ich die datei selbst anlegte.

vielleicht könntet ihr beispiele in den erklärungen
geben.

Wie soll ich das tun, ohne die Verzeichnisstruktur
Deines Servers zu kennen?

das _muss_ du nun wirklich nicht kennen. es genügt ja irgendein beispiel!

document-root:
/home/mydomain/html

beim FTP sehen Sie
/html

--
cache für cgip_cnc
/home/mydomain/gzip

beim FTP sehen Sie
/html
/gzip

--
cgi-bin für cgip_cnc
/home/mydomain/html/cgi-bin

beim FTP sehen Sie
/html/cgi-bin

--
logdatei für cgip_cnc
/home/mydomain/gzip/gzip.log

beim FTP sehen Sie
/gzip/gzip.log

-------------------

Auf meinem Webspace liegen die Dateien von URL-Raum
und sonstigen Kram beispielsweise ziemlich weit von-
einander entfernt:

• URL-Räume liegen in /www/<domainname>,
• sonstiges Zeug liegt in /home/<domainname>.
  Folglich liegen bei mir auch der Cachebaum und alle
  Log-Dateien in /home/<domainname> - also eben gerade
  _nicht_ relativ zu DOCUMENT_ROOT.
  Das wird aber bei den meisten Anwendern wieder völlig
  anders sein - oft ist der URL-Raum ein Unterverzeichnis
  des FTP-Einwahlpunktes oder was auch immer.
  Und manchmal haben die Webspaces überhaupt keinen
  Bereich außerhalb des URL-Raums ...

aber genau diesen unterschied zwischen FTP und was eigentlich? solltet ihr etwas besser hervorheben.
(bei mir liegt z.B. alles unter /home/<domainname> , also sowohl dann mein "url-baum" als auch anderen verzeichnisse.)

Fein. Ich bin gespannt auf die Komprimierungswirkung ...

.. hmm ich verstehe nicht viel davon ;-)
(aber ich sende dir mal die logdatei zu)

grüße
thomas

[Michael Schröpl]

Hallo Thomas,

Mit Problemen sollte man immer rechnen. ;-)
ich meinte aber auch fragen wie CPU-usage, denn ich möchte ja nicht, dass mich mein provider wegen CPU-"overusage" mahnt.

Dann schau in das Logfile - dort steht der gemessene
zusätzliche CPU-Verbrauch pro Request drin.
Auf dem Pentium 400 meines Providers mit Suse-Linux
liegt der so um die 0.05 CPU-Sekunden pro Request -
falls komprimiert werden muß (in momentan ca. 10%
aller Fälle, weil ich die gzip_cnc-Seiten öfters
austausche), auch mal um Faktor 2-4 höher.

ihr wolltet doch die formulierungen auch für laien
verständlich machen (?)

Ja, schon. Aber ein komplettes "how to install a CGI
script" wird gzip_cnc nicht mitliefern.

gehen wir also davon aus:
/usr/local/apache/htdocs
das ist also der document-root ... schön, aber!
geht man mit FTP auf seinem server finden man in
etwa sowas vor:
/htdocs
/logs
/ftp

Vielleicht. Bei mir nicht, beispielsweise.

Würde es etwas helfen, wenn der Selftest-Modus
http://www.schroepl.net/cgi-bin/gzip_cnc_demo.pl
den Inhalt von DOCUMENT_ROOT mit anzeigen würde?
Oder den Pfadnamen, unter dem das Skript selbst
installiert ist? Das wäre beides ganz einfach ...

das ist auch ok, aber das anlegen des cache-
verzeichnisses liegt nicht allein am script.
man muss das verzeichniss selbst anlegen (also
per FTP) und erst dann diese im script angeben.

gzip_cnc _könnte_ sehr wohl das Verzeichnis selbst
anlegen ... hältst Du das für sinnvoll?
Es würde dann halt damit enden, daß viele Benutzer
wirklich blind die Defaultwerte verwenden, also den
Cache innerhalb ihres URL-Baums liegen haben ...
Und es würde Leute mit "komischen" Servern, die
sich blind auf den Automatismus verlassen, ziemlich
im Regen stehen lassen.

Ich möchte schon voraussetzen, daß die Anwender in
etwa wissen, wie man auf ihrem Webspace ein CGI-Skript
installiert. Was ich ihnen unbedingt erklären muß,
das ist die Einbindung des Apache-Handlers.

das war mir schon klar, nur eure erklärungen dazu
waren etwas verwirrend.

Die Schuld liegt alleine bei mir - Christian war rein
als Programmier-Berater tätig.

gzip_cnc arbeitet nur mit absoluten Pfaden.
das müsst ihr aber wo auch dann sagen!

Danke - ich habe das inzwischen nachgetragen:
http://www.schroepl.net/projekte/gzip_cnc/install.htm#cacheroot
http://www.schroepl.net/projekte/gzip_cnc/install.htm#logfile
Besser so?

und es wird auch nicht gesagt, dass man die
protokolldatei erst selbst tatsächlich anlegen
soll
"soll" und muß man auch nicht.
">>" legt die Datei an, falls sie nicht existiert.
natürlich habe ich alle rechte , im error log steht nichts.
aber es wurde erst dann protokolliert als ich die datei selbst anlegte.

Moment mal: Daß _Du_ (per FTP) alle Rechte hast,
bedeutet nicht zwangsläufig, daß die Benutzerkennung,
unter welcher Dein Apache CGI-Skripte ausführt, die-
selben Rechte besitzt.

Würdest Du beispielsweise in einem Verzeichnis, das
mit "chmod 644" nur seinem owner ein Recht zur Er-
zeugung einer Datei einräumt, eine Protokolldatei
manuell angelegt und mit "chmod 777" world writable
gemacht haben, dann würde dies genau Deine Symptome
erklären ... war es ungefähr so?

document-root:
/home/mydomain/html
beim FTP sehen Sie
/html

_Ich_ sehe beim FTP aber reale Pfade!
Ich arbeite nicht in einer chroot-Umgebung.
Genau _das_ ist halt wirklich bei jedem Provider an-
ders ... das habe ich ja auch beim Punkt "Installation
des CGI-Skripts" angegeben.
Jemand, der ein Forum-Skripts installieren wollte,
hätte genau dieselben Probleme - da muß er aber durch,
dabei kann ich ihm nicht wirklich helfen.

cgi-bin für cgip_cnc
/home/mydomain/html/cgi-bin

Kann sein - muß aber nicht. Beispielsweise könnte
das CGI-Verzeichnis via "ScriptAlias" von einem
ganz anderen Laufwerk hinein gemapped worden sein.

aber genau diesen unterschied zwischen FTP und was
eigentlich? solltet ihr etwas besserhervorheben.

Bei meinem Provider existiert kein solcher Unterschied.

(bei mir liegt z.B. alles unter /home/<domainname>,
also sowohl dann mein "url-baum" als auch anderen
verzeichnisse.)

Tja, eben ...

Falls dies ein häufiges Szenario sein sollte: Hältst
Du im Skript eingetragene Default-Werte für Cache-Root
und Logfile (!) relativ zum DOCUMENT_ROOT für sinnvoll?
Das würde zumindest die Wahrscheinlichkeit erhöhen, daß
es "sofort läuft" ... aber auch die Faulheit der Be-
nutzer fördern. (Und das Logfile in den URL-Raum des
Benutzers einblenden ... hm.)

Fein. Ich bin gespannt auf die
Komprimierungswirkung ...
.. hmm ich verstehe nicht viel davon ;-)
(aber ich sende dir mal die logdatei zu)

Die aktuelle Download-Version
http://www.schroepl.net/_download/gzip_cnc.zip
enthält nun das unter
http://www.schroepl.net/projekte/gzip_cnc/logfile.htm#eval
versprochene zugehörige Logfile-Auswerteprogramm
(und eine angefangene englische Übersetzung der
ganzen Dokumentation ...). Damit kannst Du selbst
nachsehen, was gzip_cnc bei Dir so alles tut ...
(Es lohnt sich, die ersten ca. 50 Zeilen des Skripts
zu lesen.)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Thomas J.S.]

Hallo Michael,

Dann schau in das Logfile - dort steht der gemessene
zusätzliche CPU-Verbrauch pro Request drin.

ok ;-)

ihr wolltet doch die formulierungen auch für laien
verständlich machen (?)

Ja, schon. Aber ein komplettes "how to install a CGI
script" wird gzip_cnc nicht mitliefern.

_das_ habe ich ja auch nicht verlangt ,-)

gehen wir also davon aus:
/usr/local/apache/htdocs
das ist also der document-root ... schön, aber!

Vielleicht. Bei mir nicht, beispielsweise.

war/ist ja auch klar: aber es sollte eben nur als Beispiel dienen anhand ein user erkennen könnte wie er vorzugehen hat.

Würde es etwas helfen, wenn der Selftest-Modus
http://www.schroepl.net/cgi-bin/gzip_cnc_demo.pl
den Inhalt von DOCUMENT_ROOT mit anzeigen würde?
Oder den Pfadnamen, unter dem das Skript selbst
installiert ist? Das wäre beides ganz einfach ...

keine ahung ob das nützlich sein würde, aber:
-------------------------
cache root directory: [none specified] -> "/www/schroepl.net/.gzip_cnc_cache",
using the default value as none has been selected by the user
(this directory does not exist! gzip_cnc will try to create it when needed
but doesn't know right now whether this will work)  ERROR
-------------------------

gzip_cnc _könnte_ sehr wohl das Verzeichnis selbst
anlegen ... hältst Du das für sinnvoll?

bedingt, ja.
ich meine nicht, dass der script von sich selbst aus was anlegen soll sondern wenn ich ein pfad eintrage und darin ein verzeichnis nicht existiert wäre es nett wenn der scritp es erstellen würde.

Es würde dann halt damit enden, daß viele Benutzer
wirklich blind die Defaultwerte verwenden, also den
Cache innerhalb ihres URL-Baums liegen haben ...

ok, wenn ich davon ausgehen, dass gzip_cnc eh nur von leuten genutzt wird, die auch etwas davon verstehen... na ja, dann kann ja alles bleiben wie es ist.
solltet ihr aber auch "thomas normaluser" ;-) als zielgruppe haben, würden einige erweiterte erklärungen von große hilfe sein.
es geht nicht darum, dass man den user das denken abnimmt, sondern dass man ihm vielleicht noch verständlicher erklärt, welche möglichkeiten was bewirken.

Ich möchte schon voraussetzen, daß die Anwender in
etwa wissen, wie man auf ihrem Webspace ein CGI-Skript
installiert.

das ist wohl nicht das problem ... dazu haben sogut wie alle provider FQA's.

Was ich ihnen unbedingt erklären muß,
das ist die Einbindung des Apache-Handlers.

wenn du die .htaccess datei meinst: nun das sit wohl das einfachste, denn das geht wirklich schopn fast mit copy & past.

gzip_cnc arbeitet nur mit absoluten Pfaden.
das müsst ihr aber wo auch dann sagen!

Danke - ich habe das inzwischen nachgetragen:

» Besser so?

ja. :-)

und es wird auch nicht gesagt, dass man die
protokolldatei erst selbst tatsächlich anlegen
soll
"soll" und muß man auch nicht.
">>" legt die Datei an, falls sie nicht existiert.
natürlich habe ich alle rechte , im error log steht nichts.
aber es wurde erst dann protokolliert als ich die datei selbst anlegte.

Moment mal: Daß _Du_ (per FTP) alle Rechte hast,
bedeutet nicht zwangsläufig, daß die Benutzerkennung,
unter welcher Dein Apache CGI-Skripte ausführt, die-
selben Rechte besitzt.

Würdest Du beispielsweise in einem Verzeichnis, das
mit "chmod 644" nur seinem owner ein Recht zur Er-
zeugung einer Datei einräumt, eine Protokolldatei
manuell angelegt und mit "chmod 777" world writable
gemacht haben, dann würde dies genau Deine Symptome
erklären ... war es ungefähr so?

frage mich was anderes, ein "dirInfo" sagt mir zumindest folgendes:
-rw-r--r--  21910 Jun 17 03:17 gzip.log
-rwxr-xr-x  43111 Jun 13 16:13 gzip_cnc.pl

_Ich_ sehe beim FTP aber reale Pfade!
Ich arbeite nicht in einer chroot-Umgebung.
Genau _das_ ist halt wirklich bei jedem Provider an-
ders ... das habe ich ja auch beim Punkt "Installation
des CGI-Skripts" angegeben.

Falls dies ein häufiges Szenario sein sollte: Hältst
Du im Skript eingetragene Default-Werte für Cache-Root
und Logfile (!) relativ zum DOCUMENT_ROOT für sinnvoll?
Das würde zumindest die Wahrscheinlichkeit erhöhen, daß
es "sofort läuft" ... aber auch die Faulheit der Be-
nutzer fördern. (Und das Logfile in den URL-Raum des
Benutzers einblenden ... hm.)

ich glaube die meinsten probleme werden die "normaluser" sowieso damit haben, dass sie ihr dokument root herausfinden um ihn im script anzugeben.
den script zu installieren und die shebang line anzupassen wird nicht das problem sein, aber dann müssen sie noch herausfinden wie der pfad zu docoment root lautet.
(mein FTP programm zeigt das eben z.b. nicht an. und ich musste das auch mal erst per $ENV abfragen)

da fällt mir noch ein:
ich habe einige .htaccess geschützte verzeichnisse (im URL-Baum), ich habe heute festgestellt, dass wenn ich auf diese zugreifen will automatisch ein 403 bekomme (ohne dass user und PW abgefragt werden). ich habe jetzt mal gzip_cnc deaktiviert.
habt ihr dafür eine lösung?

grüße
thomas

[Michael Schröpl]

Hallo Thomas,

keine ahnung ob das nützlich sein würde, aber:

cache root directory: [none specified] -> "/www/schroepl.net/.gzip_cnc_cache",
using the default value as none has been selected by the user
(this directory does not exist! gzip_cnc will try to create it when needed
but doesn't know right now whether this will work)  ERROR

Äh, ja. Alles wahr. ;-)
Was genau würdest Du an dieser Stelle vorschlagen?

Wenn der Benutzer in der Herumprobierphase ist, soll
ich dann wirklich auf Verdacht hin überall mal solche
Verzeichnisse anlegen?

ich meine nicht, dass der script von sich selbst
aus was anlegen soll sondern wenn ich ein pfad
eintrage und darin ein verzeichnis nicht existiert
wäre es nett wenn der script es erstellen würde.

gzip_cnc legt das Verzeichnis auch tatsächlich bei
Bedarf an! Nur eben noch nicht im Selbsttest-Modus ...

solltet ihr aber auch "thomas normaluser" ;-) als
zielgruppe haben, würden einige erweiterte
erklärungen von große hilfe sein.

Haben wir, ja!
Und Deine Hinweise sind auch sehr wertvoll für mich.

es geht nicht darum, dass man den user das denken abnimmt, sondern dass man ihm vielleicht noch verständlicher erklärt, welche möglichkeiten was bewirken.

Damit tue ich mich schwer - weil die Möglichkeiten
der Apache-Konfiguration so vielfältig sind, und weil
man über das halbe Dutzend Einstellungen in gzip_cnc
auch schon relativ viel verändern kann ... und auch
die bedingte Erkennung des Komprimierungsverfahrens
ist ja nicht so ganz trivial verständlich.

Die Installationsanweisung ist einfach schon ziemlich
lang, weil ich glaube, die Hintergründe vermitteln zu
wollen - nicht einfach "macht hier den Pfad rein und
dort den Pfad, und dann wird es schon laufen".

Ich möchte den Benutzern die Möglichkeit geben, Fehler
ihrer Installation selbst zu erkennen - deshalb ja
auch der Selbsttest-Modus.

Ich möchte schon voraussetzen, daß die Anwender
in etwa wissen, wie man auf ihrem Webspace ein
CGI-Skript installiert.
das ist wohl nicht das problem ... dazu haben sogut
wie alle provider FQA's.

Wieso war dann
  http://aktuell.de.selfhtml.org/artikel/cgiperl/inbetriebnahme/
so notwendig?

Was ich ihnen unbedingt erklären muß,
das ist die Einbindung des Apache-Handlers.
wenn du die .htaccess datei meinst: nun das ist
wohl das einfachste, denn das geht wirklich schon
fast mit copy & paste.

Für den einfachsten Fall, ja. Aber was ist im
Zusammenspiel mit anderen Apache-Features?

frage mich was anderes, ein "dirInfo" sagt mir zumindest folgendes:
-rw-r--r--  21910 Jun 17 03:17 gzip.log
-rwxr-xr-x  43111 Jun 13 16:13 gzip_cnc.pl

Weder kenne ich das Kommando "dirInfo" (welches
Betriebssystem?), noch zeigt dieses Ausgabeformat
eine Benutzerkennung für den owner dieser Dateien.

Man sieht immerhin, daß die gzip.log mit "chmod 644"
berechtigt wurde (darfst Du gerne auf "600" ändern),
nicht aber, welche Zugriffsrechte auf das Verzeichnis
eine Ebene höher existieren.
Ich habe es bei mir gerade selbst nochmal ausprobiert:
gzip_cnc legt die Protokolldatei selbst an, wenn es
dies darf.

Hältst Du es für sinnvoll, eine gzip_cnc-Installation
mit fehlerhafter Definition der Protokolldatei gar
nicht "produktiv" werden zu lassen?
gzip_cnc könnte sehr wohl dem Benutzer ein Fehler-
Dokument (_statt_ der Original-Seite) zurückliefern
und darin beschreiben, was beim Versuch, in die Log-
Datei zu schreiben, passiert ist.
Das Problem dabei ist: gzip_cnc wird tendentiell ja
als Handler für _sämtliche_ Dokumente des URL-Raums
eingesetzt. Und wenn es an dieser Stelle eine Fehler-
meldung ausgeben würde (so wie sein eigenes 404-
Dokument), dann ist die gesamte Website "zugenagelt",
und das bloß wegen einer fehlerhaften Protokolldatei.
Ist es das wert? Bisher hat gzip_cnc sich anders ent-
schieden, d. h. es liefert auch in diesem Fall der
Fehlkonfiguration Dokumente aus ...

ich glaube die meinsten probleme werden die
"normaluser" sowieso damit haben, dass sie ihr
dokument root herausfinden um ihn im script
anzugeben.

Das DOCUMENT_ROOT in den Selbsttest-Modus einzublenden
wäre kein Problem.
Ich würde aber jedem Benutzer, der die Möglichkeit dazu
hat, empfehlen, den Cache eben gerade _nicht_ innerhalb
des URL-Baums anzulegen ... und _dann_ kann ich ihm
nicht erklären, wie sein Provider seine Webspace-Struk-
tur aufgebaut hat.

Ich finde es übrigens eigenartig, daß Dein Webspace
nur aus dem URL-Baum besteht, aber .htaccess erlaubt,
so daß Du gar keine Chance hast, eine .htpasswd-Datei
außerhalb des für HTTP-Angriffe sichtbaren Bereichs zu
legen ... ich halte das nicht unbedingt für den Normal-
fall. (Und .htaccess ist Voraussetzung für gzip_cnc.)

(mein FTP programm zeigt das eben z.b. nicht an.
und ich musste das auch mal erst per $ENV abfragen)

Wie gesagt: Das kann der Selbsttest-Modus erledigen.
Soll er?    [ ] ja     [ ] nein

ich habe einige .htaccess geschützte verzeichnisse (im URL-Baum), ich habe heute festgestellt, dass wenn ich auf diese zugreifen will automatisch ein 403 bekomme (ohne dass user und PW abgefragt werden). ich habe jetzt mal gzip_cnc deaktiviert.
habt ihr dafür eine lösung?

Ich kann Dein Problem bei mir nicht reproduzieren:
http://www.schroepl.net/projekte/gzip_cnc/secure/
An der Übertragungsdauer wirst Du sehen, daß diese
Datei komprimiert ausgeliefert wird.
(http_trace geht hier nicht, weil das Skript nicht
selbst Basic Authentication beherrscht.)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Thomas J.S.]

hallo Michael,

keine ahnung ob das nützlich sein würde, aber:

cache root directory: [none specified] -> "/www/schroepl.net/.gzip_cnc_cache",
using the default value as none has been selected by the user
(this directory does not exist! gzip_cnc will try to create it when needed
but doesn't know right now whether this will work)  ERROR

Äh, ja. Alles wahr. ;-)
Was genau würdest Du an dieser Stelle vorschlagen?

"ERROR" wirkt erschreckend, man meint man hätte einen fehler begangen, obwohl das wohl nicht der fall ist.
"EEROR" sollte nur wirkliche fehler anzeigen, vielleicht geht hier einfach  mal "hint" oder "note" auch.

gzip_cnc legt das Verzeichnis auch tatsächlich bei
Bedarf an! Nur eben noch nicht im Selbsttest-Modus ...

siehe oben.

es geht nicht darum, dass man den user das denken abnimmt, sondern dass man ihm vielleicht noch verständlicher erklärt, welche möglichkeiten was bewirken.

Damit tue ich mich schwer - weil die Möglichkeiten
der Apache-Konfiguration so vielfältig sind,

[...]

Die Installationsanweisung ist einfach schon ziemlich
lang, weil ich glaube, die Hintergründe vermitteln zu
wollen - nicht einfach "macht hier den Pfad rein und
dort den Pfad, und dann wird es schon laufen".

na ja... aber die meisten user möchten es einfach benutzen, so wie ich. und mir ist es nunmal nicht notwendig (aber interessant!) zu wissen wie es komprimiert wird. es reicht wenn ich weiss was wohin ich im script eintragen muss .

Ich möchte den Benutzern die Möglichkeit geben, Fehler
ihrer Installation selbst zu erkennen - deshalb ja
auch der Selbsttest-Modus.

das ist ja auch voll ok, das habe ich auch oft benutzt bevor ich den script aktiviert habe. ist eine echte hilfe!

Wieso war dann
  http://aktuell.de.selfhtml.org/artikel/cgiperl/inbetriebnahme/
so notwendig?

weil die leute generell keine FAQ's lesen?

Was ich ihnen unbedingt erklären muß,
das ist die Einbindung des Apache-Handlers.
wenn du die .htaccess datei meinst: nun das ist
wohl das einfachste, denn das geht wirklich schon
fast mit copy & paste.

Für den einfachsten Fall, ja. Aber was ist im
Zusammenspiel mit anderen Apache-Features?

da kommt genau das ins spiel was du voher erwähnt hast.
es gibt zu viele möglichkeiten auf alles rücksicht nehmen zu können.

frage mich was anderes, ein "dirInfo" sagt mir zumindest folgendes:
-rw-r--r--  21910 Jun 17 03:17 gzip.log
-rwxr-xr-x  43111 Jun 13 16:13 gzip_cnc.pl

Weder kenne ich das Kommando "dirInfo" (welches
Betriebssystem?),

keine. ein "commando" vom WS_FTP.

noch zeigt dieses Ausgabeformat
eine Benutzerkennung für den owner dieser Dateien.

Man sieht immerhin, daß die gzip.log mit "chmod 644"
berechtigt wurde (darfst Du gerne auf "600" ändern),
nicht aber, welche Zugriffsrechte auf das Verzeichnis
eine Ebene höher existieren.

tja.. ich habe aber keinen blassen schimmer wie ich solche sachen ablesen sollte. ich kann höchstens das chmod ändern.

Ich habe es bei mir gerade selbst nochmal ausprobiert:
gzip_cnc legt die Protokolldatei selbst an, wenn es
dies darf.

ok, dann war es doch ein fehler bei mir.

Hältst Du es für sinnvoll, eine gzip_cnc-Installation
mit fehlerhafter Definition der Protokolldatei gar
nicht "produktiv" werden zu lassen?

man könnte auch ohne protokolldatei gut leben.

gzip_cnc könnte sehr wohl dem Benutzer ein Fehler-
Dokument (_statt_ der Original-Seite) zurückliefern
und darin beschreiben, was beim Versuch, in die Log-
Datei zu schreiben, passiert ist.

das habe _ich_ aber nicht erwähnt bzw. verlangt.

Ich finde es übrigens eigenartig, daß Dein Webspace
nur aus dem URL-Baum besteht,

tut es nicht. aber das habe ich schon gesagt.
home/domainname/url-baum/
darunter befindet sich meine website.

home/domainname/gzipcahceverzeichniss/
darunter liegen jetzt die komprimierte dateien vom gzip_cnc

und es gibt noch
home/domainname/dies und
home/domainname/das

aber .htaccess erlaubt,
so daß Du gar keine Chance hast, eine .htpasswd-Datei
außerhalb des für HTTP-Angriffe sichtbaren Bereichs zu
legen ... ich halte das nicht unbedingt für den Normal-
fall. (Und .htaccess ist Voraussetzung für gzip_cnc.)

ich kann .htaccess unter
home/domainname/.htaccess anlegen. also sehr wohl auch ausserhalb des url-baumes. in der tat leigt eine .htaccess dort (darin ist auch die aktivierung vom gzip_cnc untergebracht)

(mein FTP programm zeigt das eben z.b. nicht an.
und ich musste das auch mal erst per $ENV abfragen)
Wie gesagt: Das kann der Selbsttest-Modus erledigen.
Soll er?    [ x] ja     [ X] nein

sorry!
ja: weil so die unerfahren user dies auch schnell herausfinden können.
nein: weil ich z.b. en nicht will, dass es jeder der mal den script direkt aufruft erfahren kann.

also entweder wirklich nicht machen lassen.
oder nur wenn man z.B. nach dem test diese zeile auskommentieren kann.
(ok ich könnte noch in einem .htacees im cgi-bin z.B.
<Files gzip_cnc.pl>
Order allow,deny
Allow from www.meta-text.net
Deny from all
</Files>
schreiben ... )

ich habe einige .htaccess geschützte verzeichnisse (im URL-Baum), ich habe heute festgestellt, dass wenn ich auf diese zugreifen will automatisch ein 403 bekomme (ohne dass user und PW abgefragt werden). ich habe jetzt mal gzip_cnc deaktiviert.
habt ihr dafür eine lösung?

Ich kann Dein Problem bei mir nicht reproduzieren:

ich habe gzip_cnc wieder aktiviert:
http://www.meta-text.net/gzip/

es liegt ein index.html im verzeichniss eine .htaccess und eine .htpasswd

grüße
thomas

[Michael Schröpl]

Hallo Thomas,

"ERROR" wirkt erschreckend, man meint man hätte einen fehler begangen, obwohl das wohl nicht der fall ist.
"EEROR" sollte nur wirkliche fehler anzeigen, vielleicht geht hier einfach  mal "hint" oder "note" auch.

Okay, werde ich berücksichtigen.
(Vielleicht lege ich das Verzeichnis wirklich auch schon im
Selbsttest-Modus an und lösche es gleich wieder ...)

das ist ja auch voll ok, das habe ich auch oft benutzt bevor
ich den script aktiviert habe. ist eine echte hilfe!

Fein - das zu hören bringt mir auch etwas.

Dann werde ich diesen Modus tendentiell weiter entwickeln, obwohl
er für die reine Funktionalität nicht notwendig ist und knapp 50%
des Quelltexts kostet.

weil die leute generell keine FAQ's lesen?

Schluchz ... dann lesen sie aber auch meine Doku nicht ...

gzip_cnc könnte sehr wohl dem Benutzer ein Fehler-
Dokument (_statt_ der Original-Seite) zurückliefern
und darin beschreiben, was beim Versuch, in die Log-
Datei zu schreiben, passiert ist.
das habe _ich_ aber nicht erwähnt bzw. verlangt.

Okay, klar.

Ich finde es übrigens eigenartig, daß Dein Webspace
nur aus dem URL-Baum besteht,
tut es nicht. aber das habe ich schon gesagt.

Verstanden.

(mein FTP programm zeigt das eben z.b. nicht an.
und ich musste das auch mal erst per $ENV abfragen)
Wie gesagt: Das kann der Selbsttest-Modus erledigen.
Soll er?    [ x] ja     [ X] nein
ja: weil so die unerfahren user dies auch schnell herausfinden können.
nein: weil ich z.b. en nicht will, dass es jeder der mal den script direkt aufruft erfahren kann.

Danke.

Den zweiten Punkt kannst Du aber umgehen - Du kannst das Skript
beliebig umbenennen:
  http://www.schroepl.net/projekte/gzip_cnc/install.htm#cgiscript
Niemand muß seinen Namen wissen - und verlinkt ist es ja auch
nirgendwo. (Den Security-Aspekt werde ich an dieser Stelle erwähnen.)

Insofern tendiere ich dazu, das in der nächsten Version einzubauen.

oder nur wenn man z.B. nach dem test diese zeile auskommentieren kann.

Kannst Du im Prinzip auch machen:

---------------------------------------------------------------------

standardize directory separator in requested URL path

my $path_translated = $ENV{'PATH_TRANSLATED'} || '';
  if ($^O =~ /Win32/i)
     { $path_translated =~ tr!\!/!; }

split translated path into directory and filename

if ($path_translated !~ /^(.*)/([^/]+)$/)
     {
       # --------------------------------------------------------------
       # (if we aren't a handler we just display diagnostic infos to stdout)
         self_test ();
       # --------------------------------------------------------------
     }

Da könnte statt
         self_test  ();
auch
         handle_404 ('40:NO_PATH_TRANSLATED', $pathname_requested);
stehen
(stand dort auch so ähnlich vor dem Einbau der Selbsttest-Funktion).

Das könnte ich auch bedingt über ein Flag im Konfigurations-Abschnitt
machen ... wäre das sinnvoll?
Über dieses Flag könnte man dann den Selbsttest ein- und ausschalten.

(http://www.schroepl.net/projekte/gzip_cnc/source.htm)

(ok ich könnte noch in einem .htacees im cgi-bin z.B.
<Files gzip_cnc.pl>
Order allow,deny
Allow from www.meta-text.net
Deny from all
</Files>
schreiben ... )

So ähnlich denke ich mir das auch:

deny    from all
   allow   from your-server
   satify  any
   require valid-user

Dann könntest Du mit Angabe eines Passworts darauf zugreifen.

Ich kann Dein Problem bei mir nicht reproduzieren:
ich habe gzip_cnc wieder aktiviert:
http://www.meta-text.net/gzip/

Na, dann schauen wir uns das mal an:

[ 17] HTTP/1.0 200 Okay
[ 35] Cache-Control: public,max-age=86400
[ 17] Connection: close
[ 35] Date: Tue, 18 Jun 2002 02:08:19 GMT
[ 58] Server: Apache/1.3.3 (Unix) PHP/4.1.2 FrontPage/5.0.2.2510
[ 21] Vary: Accept-Encoding
[ 59] WWW-Authenticate: Basic realm="User: selfhtml PW: selfhtml"
[ 22] Content-Encoding: gzip
[ 19] Content-Length: 439
[ 23] Content-Type: text/html
[ 38] Expires: Wed, 19 Jun 2002 02:08:19 GMT
[ 44] Last-Modified: Mon, 17 Jun 2002 08:16:36 GMT
[ 33] X-Gzipcnc-Original-File-Size: 752
[ 36] X-Gzipcnc-Version: 1.05 (2002-06-09)

Alles, was ich sehen kann, ist:
a) Dein Apache 1.3.3. ist _uralt_. (10. Oktober 1998)
   Vielleicht behandelt der die Action/handler-Schnittstelle anders
   als meine Maschinen (1.3.12/Suse bzw. 1.3.23/Win98)?
b) Er sendet meinem HTTP-Trace-Skript einen Authenticate-Header,
   was ja soweit okay zu sein scheint.
c) Er sendet aber einen HTTP-Status 200 zurück - nicht 401, wie er
   sollte, wenn er eine Authentifizierung verlangt.
d) Deine 401-Fehlerseite wird allerdings von gzip_cnc komprimiert
   ausgeliefert.
Hm ... der Status 200 kommt natürlich von gzip_cnc selbst, welcher
den HTTP-Header zusammenstellt. Der Apache mischt dann seine eigenen
Header dazu, und ab damit. Hm ... ich muß mal sehen, ob ich diesen
401er-Status erkennen kann, wenn ich aufgerufen werde ... das könnte
tatsächlich ein Problem sein. Allerdings: Bei mir funktioniert es ...

Ich muß auch mal ausprobieren, was passiert, wenn gzip_cnc nicht selbst
versucht, einen HTTP-Status zu senden - dann müßte das ja der Apache
tun. Dann käme wohl immerhin eine 401 zurück statt einer 200 ... ob
dies das Problem irgendwie lösen hilft (das ich selbst ja nicht habe),
vermag ich aber nicht zu sagen.

Viele Grüße, und vielen Dank für das Testfliegen
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Thomas J.S.]

Hallo Michael,

nein: weil ich z.b. en nicht will, dass es jeder der mal den script direkt aufruft erfahren kann.

Den zweiten Punkt kannst Du aber umgehen - Du kannst das Skript
beliebig umbenennen:

ich weiss es ja, aber bei sowas gehe gerne nunmal auf sicher. ;-)

Insofern tendiere ich dazu, das in der nächsten Version einzubauen.
Das könnte ich auch bedingt über ein Flag im Konfigurations-Abschnitt machen ... wäre das sinnvoll?
Über dieses Flag könnte man dann den Selbsttest ein- und ausschalten.

ja. das wäre eine gute idee für die nächste version.

Ich kann Dein Problem bei mir nicht reproduzieren:
ich habe gzip_cnc wieder aktiviert:
http://www.meta-text.net/gzip/

Na, dann schauen wir uns das mal an:

[ 17] HTTP/1.0 200 Okay
[ 35] Cache-Control: public,max-age=86400
[ 17] Connection: close
[ 35] Date: Tue, 18 Jun 2002 02:08:19 GMT
[ 58] Server: Apache/1.3.3 (Unix) PHP/4.1.2 FrontPage/5.0.2.2510
[ 21] Vary: Accept-Encoding
[ 59] WWW-Authenticate: Basic realm="User: selfhtml PW: selfhtml"
[ 22] Content-Encoding: gzip
[ 19] Content-Length: 439
[ 23] Content-Type: text/html
[ 38] Expires: Wed, 19 Jun 2002 02:08:19 GMT
[ 44] Last-Modified: Mon, 17 Jun 2002 08:16:36 GMT
[ 33] X-Gzipcnc-Original-File-Size: 752
[ 36] X-Gzipcnc-Version: 1.05 (2002-06-09)

Alles, was ich sehen kann, ist:
a) Dein Apache 1.3.3. ist _uralt_. (10. Oktober 1998)

tja... darauf habe ich keinen einfluß und muss damit leben!

Vielleicht behandelt der die Action/handler-Schnittstelle anders

tja... mal sehen ob ich was im .htaccess einstellen kann... könnte man dem script nicht einen user und pw verpassen?
ich habe ja schon in anderen verzeichnissen dateien explizit erlaubt bzw. ausgeschlossen von einem anzeigen

d) Deine 401-Fehlerseite wird allerdings von gzip_cnc komprimiert
   ausgeliefert.

ja, das fand ich lustig ;-)

Viele Grüße, und vielen Dank für das Testfliegen

ebenfalls und gerne....
die gzipten seitne werden wirklich viel schneller geladen, also würde ich den scritp gerne nutzen ;-)

thomas

[Michael Schröpl]

Hallo Thomas,

Insofern tendiere ich dazu, das in der nächsten Version einzubauen.
Das könnte ich auch bedingt über ein Flag im Konfigurations-Abschnitt machen ... wäre das sinnvoll?
Über dieses Flag könnte man dann den Selbsttest ein- und ausschalten.
ja. das wäre eine gute idee für die nächste version.

Ist drin:
http://www.schroepl.net/projekte/gzip_cnc/changes.htm#v1.06

Und einiges andere von Deinen Anregungen ebenfalls ...
die Installationsanleitung ist auch länger geworden.

tja... mal sehen ob ich was im .htaccess einstellen
kann... könnte man dem script nicht einen user und
pw verpassen?

Das Problem ist, daß ich mir gar nicht vorstellen kann,
wie gzip_cnc in das Problem verwickelt sein könnte.
Insbesondere setzt gzip_cnc selbst ja keinen HTTP-
Request ab - ich wüßte also nicht, wie das irgend
jemandem eine Server Authentication übermitteln sollte.

Bei allen anderen mir bekannten Aspekten der Vorbe-
handlung des Requests macht vorher der Apache alles
Nötige und ruft den Handler erst auf, wenn der fertig
übersetzte Dateiname fest steht.
(Deshalb funktioniert bei mir ja auch die komprimierte
Auslieferung der gzip_cnc- und mod_gzip-Dokumente, ob-
wohl beide gleichzeitig auch noch über die Sprache con-
tent negotiated werden - gzip_cnc merkt davon gar nix.)

Könntest Du mal ein triviales CGI-Skript, das einfach
nur alle Environment-Variablen ausgibt, als Handler in
einem geschützten Bereich bei Dir einbinden? Falls es
am Apache liegt, dann müßte das ja dieselben Probleme
haben ...

ich habe ja schon in anderen verzeichnissen dateien
explizit erlaubt bzw. ausgeschlossen von einem
anzeigen

Du könntest Dein geschütztes Unterverzeichnis separat
von der Komprimierung ausnehmen, indem Du in _dessen_
.htaccess-Datei die HTML-Dateien (welches Muster das
bei Dir auch immer sein mag) dem Apache-Default-Handler
zuordnest - der heißt auch wirklich "default-handler".

Dann kannst Du wenigstens den Rest drum herum schon mal
komprimiert ausliefern, ohne dafür Deinen Webspace mit
.htaccess-Dateien pflastern zu müssen.

die gzipten seiten werden wirklich viel schneller
geladen, also würde ich den script gerne nutzen ;-)

Was mich interessieren würde, das wäre die Rate der
Browser, die "Accept-Encoding: gzip" senden ... bei
mir laufen in letzter Zeit relativ heftig Suchmaschi-
nen herum, die dafür zu dumm sind (muß ich echt mal
mit den Google-Leuten diskutieren), und die machen
mir den mittleren Komprimierungsfaktor arg kaputt ...
(_Wenn_ bei mir Dokumente komprimiert werden, dann im
Mittel um 70% - inklusive HTTP-Overhead - das ist aber
momentan nur in 23% aller Zugriffe der Fall.)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael