nicht angemeldet
Website g-zip'ed an client schicken?
Normalerweise sendet der Client ja den accept-encoding header-part und gibt darin an was er unterstützt, gzip, compress, deflate..
ich möchte mit meinem php-script jetzt NURNOCH gzip'ten content zurückschicken..
browser die kein gzip unterstützen bekommen ne fehlermeldung..
alle anderen sollen die webseite eben gezippt bekommen..
WIE gehe ich da vor?
ICH will NICHT auf dem server gzip starten und die seite zippen lassen.. das killt ja jede performance..
Wie packe ich das jetzt also an ? :)
Müsste ich den webserver entsprechend konfigurieren (was mir nicht möglich ist, 1&1 webspace)
oder wie mach ich das ?
mfG
Manuel
-
Hallo,
würde mich auch interessieren, aber müsste da nicht die komplette html-datei gezippt auf den Server, oder womöglich noch eine Info für den Browser?
Falls das klappt ist es aber wohl nichts mehr mit PHP, ich vermute mal dass es kaum möglich wäre gezippte Fragmente per PHP zusammenzukleben.
Grüsse,
CurtB
-
Moin!
ich möchte mit meinem php-script jetzt NURNOCH gzip'ten content zurückschicken..
browser die kein gzip unterstützen bekommen ne fehlermeldung..
alle anderen sollen die webseite eben gezippt bekommen..Warum sowas? Content Negotiation ist doch genau dafür da, dem Client bedarfsweise die richtige Version zu liefern.
WIE gehe ich da vor?
ICH will NICHT auf dem server gzip starten und die seite zippen lassen.. das killt ja jede performance..Nö, das klappt eigentlich ganz prima - zum Beispiel auf diesem Server hier, und der steht nicht gerade im Verdacht, rumzuidlen.
Wie packe ich das jetzt also an ? :)
Lies die Dokumentation. http://www.php.net/manual/en/function.ob-gzhandler.php
- Sven Rautenberg
--
Signatur oder nicht Signatur - das ist hier die Frage! -
Hallo Manuel,
browser die kein gzip unterstützen bekommen ne fehlermeldung..
alle anderen sollen die webseite eben gezippt bekommen..Ist Dir klar, daß z.B. Googlebot kein gzip-encoding unterstützt, und Du damit aus Google rausfällst?
WIE gehe ich da vor?
ICH will NICHT auf dem server gzip starten und die seite zippen lassen.. das killt ja jede performance..Am einfachsten ist am Anfang der Seite:
<? ob_start("ob_gzhandler"); ?>
und am Ende:
<? ob_end_flush(); ?>Damit bekommen alle, die gzip akzeptieren, die Seite komprimiert, der Rest normal, aber das ist doch eigentlich die bessere Lösung, statt eine Fehlermeldung zu produzieren, oder?
Natürlich führt das dazu, daß bei jedem Seitenaufruf das Resultat einmal durch den gzip-Algorithmus geschickt wird, aber meistens läßt sich das nicht umgehen (PHP-Seiten dienen ja oft auch dazu, daß nicht jeder User die gleiche Seite bekommt, also z.B. an Urls angehängte Session-Ids, da wäre vorheriges zippen sowieso unmöglich). Außerdem ist die Performance-Einbuße minimal, zumindest nach meiner Erfahrung - eine PHP-Seite ist sowieso schon durch den PHP-Prozessor gelaufen, hat ein oder mehrere Male eine Datenbank abgefragt, usw., da ist die zusätzliche Zeit für das zippen vernachlässigbar. Und 1&1 hostet ja nicht auf einem C64 ;-).Viele Grüße
Stephan-
Hi!
Ist Dir klar, daß z.B. Googlebot kein gzip-encoding unterstützt, und Du damit aus Google rausfällst?
Sicher? Er sendet zwar keinen entsprechenden encoding-Header, dafür folgenden accept-Header:
text/html,text/plain,application/pdf,application/x-shockwave-flash,application/vnd.ms-excel,application/rtf,application/msword,application/vnd.ms-powerpoint,application/postscript,application/x-gzip,application/octet-stream,application/*
Wobei ich nicht weiß ob das so funktioniert.
Grüße
Andreas-
Hallo Andreas,
Wobei ich nicht weiß ob das so funktioniert.
http://www.webmasterworld.com/forum3/7795.htm
Zumindest also höchstens ein Teil der Crawler. Und selbst wenn Googlebot das in der nächsten Version kennen sollte, gibt es sicher noch genügend Robots, die das nicht können.
Viele Grüße
Stephan
-
-
Hallo Manuel,
browser die kein gzip unterstützen bekommen ne fehlermeldung..
alle anderen sollen die webseite eben gezippt bekommen..Ist Dir klar, daß z.B. Googlebot kein gzip-encoding unterstützt, und Du damit aus Google rausfällst?
naja, google kann alle infos aus der index.html holen :)
aber ich bin nicht auf google angewiesen ;)WIE gehe ich da vor?
ICH will NICHT auf dem server gzip starten und die seite zippen lassen.. das killt ja jede performance..Am einfachsten ist am Anfang der Seite:
<? ob_start("ob_gzhandler"); ?>
und am Ende:
<? ob_end_flush(); ?>ich muss sagen, php überrascht mich immer wieder *g*
klasse :)Damit bekommen alle, die gzip akzeptieren, die Seite komprimiert, der Rest normal, aber das ist doch eigentlich die bessere Lösung, statt eine Fehlermeldung zu produzieren, oder?
das hat einen gewissen hintergrund..
ich schreibe ein massive multiplayer onlinegame auf webbrowser basis (ja, wo es schon viele viele gibt, drum muss nen neues spielprinzip her :) )
was ich verhindern möchte ist die steuerung durch scripte dritter..
zum einen mache ich das mittels einer zufälligen zahl die als bild dargestellt wird und die eingegeben werden muss..
also bräuchte das steuernde script ocr-fähigkeit :)gzip möchte ich einerseits zum reduzieren des traffic's, andererseits bedeutet es mehr rechenleistung für die scripte den content erst zu dekomprimieren..
wer galaxywars.de kennt:
dort kann man flotten verschicken um andere anzugreifen und somit rohstoffe zu erbeuten..
ich habe dazu scripte geschrieben die in kürzester zeit 100e flotten versenden, viel schneller als man das über die formulare von galaxywars könnte..
aber das benötigt schon so sehr viel performance, da die perlscripte je nach anzahl der flottenaufträge durchaus einige stunden laufen können..
da kommt auch schonmal bei 1&1 das nette cgi-limit reached :)
wenn ich die pages vorher noch dekomprimieren müsste hätte ich dieses limit schon viel früher..Natürlich führt das dazu, daß bei jedem Seitenaufruf das Resultat einmal durch den gzip-Algorithmus geschickt wird, aber meistens läßt sich das nicht umgehen (PHP-Seiten dienen ja oft auch dazu, daß nicht jeder User die gleiche Seite bekommt, also z.B. an Urls angehängte Session-Ids, da wäre vorheriges zippen sowieso unmöglich). Außerdem ist die Performance-Einbuße minimal, zumindest nach meiner Erfahrung - eine PHP-Seite ist sowieso schon durch den PHP-Prozessor gelaufen, hat ein oder mehrere Male eine Datenbank abgefragt, usw., da ist die zusätzliche Zeit für das zippen vernachlässigbar. Und 1&1 hostet ja nicht auf einem C64 ;-).
nunja, ob die zeit so vernachlässigbar ist muss ich testen..
es kommt ja ne sehr hohe belastung auf den server zu und ichmöchte ihn nicht unnötig stark verlangsamen..dankeschön für die infos :)
mfG
Manuel-
Moin!
das hat einen gewissen hintergrund..
ich schreibe ein massive multiplayer onlinegame auf webbrowser basis (ja, wo es schon viele viele gibt, drum muss nen neues spielprinzip her :) )
was ich verhindern möchte ist die steuerung durch scripte dritter..Das verhinderst du keinesfalls durch gzip-Encoding. Da brauchst du irgendeinen Bestandteil, welcher menschliche Intelligenz notwendig macht und Computerverarbeitung unmöglich.
Außerdem fragen nicht alle Browser nach gezipptem Inhalt - du würdest also auch reguläre Benutzer ausschließen. Der IE hat beispielsweise Default-Einstellungen, die gezippten Content nicht abfragen, wenn man über Proxys geht oder gehen muß.
Natürlich kannst du die HTTP-Header analysieren und Anfragen, die offensichtlich von einem Skript kommen, verwerfen, aber es ist ein leichtes, die HTTP-Header "passend" zu manipulieren. Das schützt dich pro Spieler, der skripten will, genau ein Mal - danach weiß er, wie der Hase läuft.
zum einen mache ich das mittels einer zufälligen zahl die als bild dargestellt wird und die eingegeben werden muss..
also bräuchte das steuernde script ocr-fähigkeit :)Das wäre so eine Sache.
gzip möchte ich einerseits zum reduzieren des traffic's, andererseits bedeutet es mehr rechenleistung für die scripte den content erst zu dekomprimieren..
Aber wirklich nur ganz marginal. Komprimieren ist das komplizierte, Dekomprimieren hingegen ist dann ganz billig.
wer galaxywars.de kennt:
dort kann man flotten verschicken um andere anzugreifen und somit rohstoffe zu erbeuten..
ich habe dazu scripte geschrieben die in kürzester zeit 100e flotten versenden, viel schneller als man das über die formulare von galaxywars könnte..
aber das benötigt schon so sehr viel performance, da die perlscripte je nach anzahl der flottenaufträge durchaus einige stunden laufen können..
da kommt auch schonmal bei 1&1 das nette cgi-limit reached :)
wenn ich die pages vorher noch dekomprimieren müsste hätte ich dieses limit schon viel früher..Wo ist da eigentlich das Problem: Der Wettstreit verlagert sich vom ursprünglichen Spiel hin zu einem Wettstreit, wer die besseren Skripte schreibt und den schnelleren Server hat. Ist doch auch interessant, oder?
nunja, ob die zeit so vernachlässigbar ist muss ich testen..
es kommt ja ne sehr hohe belastung auf den server zu und ichmöchte ihn nicht unnötig stark verlangsamen..Performance ist natürlich immer ein Problem - allerdings hat der Selfserver hier mit gzip-codiertem Content eigentlich keinerlei Probleme. Das gesamte Forum wird so ausgeliefert, wenn es möglich ist - und der Server ist wirklich gut ausgelastet, hat mit dem gzippen aber absolut kein Problem. Du kannst das gzippen außerdem konfigurieren: Man kann maximal gzippen (Level 9), braucht dafür aber ziemlich viel Rechenzeit. Sowas lohnt sich für statischen Content, der nur ein einziges mal gezippt werden muß. Dynamischer Content hingegen muß nur leicht komprimiert werden (Level 3) - damit gewinnt man schon ganz erheblich Platz bei der Übertragung, verbraucht aber wesentlich weniger CPU-Power.
Du solltest dich deshalb auch mal mit mod_gzip auseinandersetzen, sofern du die Server-Konfiguration selbst beeinflussen kannst. Dieses Apache-Modul ist recht leistungsfähig geworden.
- Sven Rautenberg
--
Signatur oder nicht Signatur - das ist hier die Frage!-
Hiho :)
Das verhinderst du keinesfalls durch gzip-Encoding. Da brauchst du irgendeinen Bestandteil, welcher menschliche Intelligenz notwendig macht und Computerverarbeitung unmöglich.
nunja, ob es da so viel effizientes gibt ? :)
sowas wie bei www.ctcheck.de (die sicherheitsfrage) ist auch ganz nett, aber nicht viel anders als meine zahl ..Außerdem fragen nicht alle Browser nach gezipptem Inhalt - du würdest also auch reguläre Benutzer ausschließen. Der IE hat beispielsweise Default-Einstellungen, die gezippten Content nicht abfragen, wenn man über Proxys geht oder gehen muß.
das wäre dann mal wieder ein - für den IE, aber ich mag den IE dennoch sehr :)
Natürlich kannst du die HTTP-Header analysieren und Anfragen, die offensichtlich von einem Skript kommen, verwerfen, aber es ist ein leichtes, die HTTP-Header "passend" zu manipulieren. Das schützt dich pro Spieler, der skripten will, genau ein Mal - danach weiß er, wie der Hase läuft.
Da ist der Vorteil das ich selbst gerne solche Scripte schreibe..
An sowas erkennt man kein Script..zum einen mache ich das mittels einer zufälligen zahl die als bild dargestellt wird und die eingegeben werden muss..
also bräuchte das steuernde script ocr-fähigkeit :)Das wäre so eine Sache.
wie gesagt, viel mehr fällt mir nicht ein wo ich als scripter passen würde..
gzip möchte ich einerseits zum reduzieren des traffic's, andererseits bedeutet es mehr rechenleistung für die scripte den content erst zu dekomprimieren..
Aber wirklich nur ganz marginal. Komprimieren ist das komplizierte, Dekomprimieren hingegen ist dann ganz billig.
wohl auch wahr, wo es mir dann eher weniger nützt, also werd ich keinen zwingen gzip-fähigen browser zu benützen :)
[-cut-]
Wo ist da eigentlich das Problem: Der Wettstreit verlagert sich vom ursprünglichen Spiel hin zu einem Wettstreit, wer die besseren Skripte schreibt und den schnelleren Server hat. Ist doch auch interessant, oder?
nur für die scripter selbst *g*
ich hab keinen spass mehr an den spielen die ich durch scripte steuern lasse.. aber sonst könnte die sucht zu gross werden und so hab ich nen tag spass nen schönes script zu schreiben *g*[-cut-]
Du solltest dich deshalb auch mal mit mod_gzip auseinandersetzen, sofern du die Server-Konfiguration selbst beeinflussen kannst. Dieses Apache-Modul ist recht leistungsfähig geworden.
Auf dem develop-server kann ich dies nicht, auf dem späteren aber schon, danke, ich schau es mir an :)
- Sven Rautenberg
Danke :)
Manuel
-
-
-