Hi all,

Die entscheidung fuer diese SQL-Loesung ist aber jetzt erst gefallen nachdem
sich die bisherige Loesung als unzuverlässig erwies, oder?

Mir gings darum, dass so umfangreiche Projekte die auch noch "nebenberuflich"
betrieben werden ihre Zeit brauchen bis neue Features realisiert werden,
insbesondere weil sich im Praxistest dann immer wieder neue dringendere
Probleme ergeben.

Mehrere Monate zu veranschlagen um serverseitig sowas wie optionales
target="reader" zu realisieren halte ich fuer realistisch waehrend eine
JS-Loesung quasi sofort funzen wuerde.

On the other hand: Ihr habt euer Konzept und wollt es erst bewältigt
haben bevor ihr andere Ansätze inlusive Schwächen riskiert. Find ich Schade
aber nachvollziehbar.

In diesem Sinne viel Erfolg noch! :)

Viele Grueße
Rolf

PS: Ob nun komprimiert oder nicht, die Forumshauptdatei ist immer noch viel
größer als als die einzelnen postings, und serverüberlastung ist immer noch ein
Thema. Ich glaube [1] deswegen immer noch das ein target=reader diese Belastung
senken würde, egal wie "modern" der Browser ist.
Die target-Option zu verfolgen würde sich also bestimmt rentieren,
unabhängig davon wann und wie sie realisiert wird.

[1] @Frank: Eine Hypothese zu postulieren und durchzudenken ist durchaus
wissenschaftlich und wird in der Wissenschaftstheorie auch gefordert. Siehe
z.B. die Menge an verschiedenen Atommodellen. Einstein, Bohr, Heisenberg etc
haben das ständig gemacht.
Gegenfrage: wenn du die Serverlogs parst und pro IP aufschlüsselst wie
oft die Hauptdatei und wie oft einzelen Postings abgerufen werden, wird
sich IMHO zeigen das die Hauptdatei >50% aller downloads ausmacht, was meine
These untermauert. Bei Bedarf fuer ich diese Auswertung auch selbst durch!

Hallo Rolf!

90% Kompression sind fuer einige Leute hier ein Argument fuer
OS und Browserwechsel!

<div style="finster">Es haben schon Leute für weniger getötet</div>

Ich hab mal ein wenig rumprobiert: Kompression gibts wenn der Browser HTTP/1.1 benutzt.
Funktionieren täte es allerdings auch mit nem 4er Netscape. Ich hab dafür folgendes PHP-Script benutzt:

<?
    $host="forum.de.selfhtml.org";

if(isset($m) && isset($t)) //Nachrichtenlinks umleiten
    {   header ("Location: http://$host/?m=$m&t=$t");
       exit;
    }

// Forum anfordern
    $loc="/";

$fp = fsockopen($host, 80, &$errno, &$errstr, 15);
    if($fp)
    {
        fputs($fp,"GET $loc HTTP/1.1\r\n");
        fputs($fp,"Host: $host\r\n");
        fputs($fp,"Accept-Encoding: gzip\r\n");
        fputs($fp,"User-Agent: $HTTP_USER_AGENT\r\n");
        fputs($fp,"Connection: close\r\n");

fputs($fp,"\r\n");  // Header Ende

while(!feof($fp))
        {
            $c=fgets($fp,133);
            if($c=="\r\n")
             break;            // Header Ende =Leerzeile erkannt
        }
        header("Content-Type: text/html");
        header("Content-Encoding: gzip");
 $in=fread($fp,54321);
 echo $in;
 fclose($fp);
     }
     else
     {
      die(" Nix Connect: Error! Host:$host Location:$loc Status:$status Errno:$errno Errstr:$errstr\n");
     }
?>

Speichern als gzget.php, ins gleiche Verzeichnis noch eine .htaccess mit
  DirectoryIndex gzget.php

und wenn du dann in deinen Netscape 4.7 dein.server.de/.../gzget.php eingibst kommt auch der NN4 in den genuss komprimierter Daten.
Die .htaccess ist für Funktionieren der Nachrichtlinks nötig.

Gruss,
 Carsten

Hallo Jens!

Tach,

Netscape 4 kann kein 'Accept-Encoding: gzip' beim http Requests, also muss der arme Apache 250Kilo ASCII rausschaufeln.

Unsinn.

Stimmt... zumindest bietet er gzip an. Hätte ich wohl doch lieber selber nachgucken sollen :(

Aber RFC2616 sagt:
A server MUST NOT send transfer-codings to an HTTP/1.0
   client.

Es handelt sich nicht um transfer-coding.

Jens

Hi Christian!

Man merkt, dass du keine Ahnung hast. Haettest du dich nur ein wenig mit
der Sachlage beschaeftigt, wuesstest du, dass Netscape 4.x zwar den Header
schickt, aber weder so encodierte Inhalte drucken kann, noch deren Source
anzeigen kann, noch CSS oder JS entpackt.

Das stimmt nicht. Er kann den Source anzeigen, das habe ich gerade ausprobiert. Das andere weiss ich nicht. Da ich kein gzip mehr geschickt bekomme, nuetzt es nichts, wenn ich jetzt CSS anschalte. (Aber was will Netscape 4 ueberhaupt mit CSS?)

Was auch richtig ist: Accept-Encoding ist HTTP/1.1, und wenn das ausgeschaltet
ist, dann darf dieser Header auch nicht geschickt werden. Basta. Alles andere
ist Lug und Trug.

Das ist auch falsch. Accept-Encoding und Content-Encoding sind in RFC1945 spezifiziert - sie sind also HTTP/1.0. Dass Netscape sogesehen luegt, stimmt aber trotzdem: Er sendet den Host-Header mit, den es erst seit HTTP/1.1 gibt. Ohne diesen Header ware aber fast kein moderner Webserver (namebased virtual hosts) mehr erreichbar, auch die Domains *.teamone.de nicht. Konsequenterweise duerfte also keiner mehr mit Netscape 4 hier rumsurfen. Ich bin mir aber nicht sicher, ob das ueberhaupt stimmt, dass kein Header einer hoeheren Version geschickt werden darf.

So long

Hoi,

Tach,

Das ist so nicht ganz richtig. Der Netscape luegt und schickt den header,
obwohl er es nicht richtig kann.

Nichts anderes habe ich gesagt.

Unsinn.
Der Netscape 4 dekomprimiert CSS und JS unter Umständen nicht.
Warum man ihn mit unzuverlässigen Mitteln von der Komprimierung der Hauptdatei ausschließt, muß der Normalsterbliche wohl nicht verstehen.

Man merkt, dass du keine Ahnung hast. Haettest du dich nur ein wenig mit der Sachlage beschaeftigt, wuesstest du, dass Netscape 4.x zwar den Header schickt, aber weder so encodierte Inhalte drucken kann, noch deren Source anzeigen kann,

Das ist nun wirklich kein Problem. Man kann eine Seite nämlich abspeichern und dann drucken, oder auch den Source angucken.
Mal davon abgesehen: Warum sollte jemand die Hauptdatei drucken wollen?

noch CSS oder JS entpackt.

Auch das habe ich gesagt. Was hat das mit der Hauptdatei zu tun?

Accept-Encoding ist HTTP/1.1,

Da hast du Recht.

und wenn das ausgeschaltet ist, dann darf dieser Header auch nicht geschickt werden. Basta. Alles andere ist Lug und Trug.

Accept-Encoding ist allerdings auch HTTP/1.0. Das kannst du in RFC 1945 nachlesen. Das ist die Spezifikation dazu.

Jens