FB 7240 zusätzlich als Webserver nutzten

[neuland]

Hallo zusammen,

möchte gerne meine Fritzbox für Webentwicklungen einen xampp für Linux laufen lassen.

Benötige ich hierzu Freetz oder gibe es bessere Alternativen?

Gibt ein Packet wie xampp für die Fritzbox?

Kennt jemand vielleicht auch entsprechende Anleitungen / Tutorials?

Danke für eure Hilfe!

 

[HabNeFritzbox]

Schonmal Suche benutzt?

Google 1. Ergebniss dieses Forum
https://www.google.de/search?q=xampp+fritzbox

Oder Forum Suche?
http://www.ip-phone-forum.de/showthread.php?t=103110

Spaß dürfte da eher weniger aufkommen, die FB ist nicht dafür gut geeignet, besonders mit PHP und MySQL.

 

[koyaanisqatsi]

Aber: (hihi)
Wenn du ©Apache für die Box willst dann frag ©Radislav

Ansonsten:
Schau dir freetz mal ganz genau an, dann lernst du auch was über

Webentwicklungen

(Hab ich nicht ©Apache bei den freetz Paketen gesehen?)

PS: Dank meto entwickle ich grad sowas hier

 

[hermann72pb]

@koyaanisqatsi: Ich hatte dir in dem zitierten Thread was dazu gepostet: Bitte achtet darauf, dass ihr im richtigen Unterforum postet, sonst besteht die Gefahr, dass eure guten Sachen einfach "runtergehen".
Ich finde die Idee mit dem httpd gar nicht so schlecht. Wir nutzen den httpd doch schon mehrfach unter FREETZ. Dass man noch einen WebIF-konfigurierbaren Dienst daraus macht, dass jeder Benutzer die Sachen frei einstellen kann ist auch eine gute Idee. Es muss nicht immer Apache und Co. sein. Vieles kann man auch mit httpd erreichen.

MfG

 

[neuland]

Danke für eure Infos!

 

[koyaanisqatsi]

Gerne doch,
hab übrigens grad hearausgefunden das der httpd auch komprimierte Seiten ausliefern kann (entsprechende Option in busybox einkompilierbar),
so daß man ganz ganz ganz viel Text in der index.html zu ganz kleiner Dateigrösse in index.html.gz komprimieren kann

 

[hermann72pb]

Und wozu ist es gut? Können die Browser damit umgehen?
gz-Komprimierung ist übrigens nicht so stark und bringt nicht unbedingt viel, obwohl es gerade für Texte wahrscheinlich ausreichen würde. Dass man mit busybox-Mitteln gz-komprimieren kann ist auch nicht neu. Das hatte ich schon zu den Zeiten vom downloader zu Nutze gemacht. Darum wundert es mich nicht, dass man es in http "einkompilieren" kann. Andere Komprimierungsalgorithmen wären wahrscheinlich auch möglich, wenn auch mit etwas mehr Aufwand.
Bei der Komprimierung sollte man auf den RAM-Verbrauch achten. Für Flash-Vorgänge werden z.B. PIPE-s benutzt, um das Zwischenspreichern zu ersparen.
Zusammengefasst: Möglich ist vieles, man sollte aber nur sinnvolle Sachen treiben.

MfG

 

[koyaanisqatsi]

Viel Text halt.
Soweit ich das beurteilen kann, kann es dem Browser egal sein, weil er die unkromprimierte index.html ausgeliefert bekommt.
Das Dekromprimieren übernimmt also der httpd.

Und wozu ist es gut? Können die Browser damit umgehen?

(tschuldigung, dass ich sooo alte Sachen entdecke)

 

[hermann72pb]

...Soweit ich das beurteilen kann, kann es dem Browser egal sein, weil er die unkromprimierte index.html ausgeliefert bekommt.
Das Dekromprimieren übernimmt also der httpd...

:bahnhof:
Der httpd sitzt doch serverseitig, Browser ist klientseitig. Normalerweise macht es Sinn die Informationen VOR der Übertragung zum Klient beim Server zu komprimieren und dann NACH der Übertragung beim Klient wieder zu dekomprimieren. Mir ist ein bisschen rätselhaft, wie der httpd-Server die klientseitige Dekomprimierung übernehmen kann. Mag sein, dass ich da irgendwas übersehe. Dan kläre mich bitte auf, wie sowas möglich ist.
Genau darum hatte ich ja gefragt, wozu sowas gut sein könnte. Meine Fragen haben schon einen Hintergrund...

MfG

 

[koyaanisqatsi]

Klient fragt: hast du mal / für mich?
httpd: Klar / ist da Standardstartdatei ist index.html, index.html nicht da aber index.html.gz, dekomprimiere index.html.gz und liefere index.html aus .... fertig
Klient: /index.html bekommen, dankeschön

 

[hermann72pb]

Du hast mich immer noch nicht verstanden:
In deinem Beispiel findet die Komprimierung und die Dekomprimierung (beides) auf der Serverseite VOR der Auslieferung statt. Wo ist bitteschön der Sinn der Sache? Wozu soll er das denn komprimieren? Um gleich wieder zu dekomprimieren?
Entweder hast du den Sinn der Sache nicht verstanden, oder die Option ist nutzlos.

Was ich mir eher vorstellen könnte: Im http-Protokoll gibt es irgendeine Möglichkeit, die Übertragung zu komprimieren. Dann müssen aber auch die Klients (Browser) "mitspielen". Meine Frage ging daher in die Richtung:
a) Ob http überhaupt eine solche "Hintertür"-Möglichkeit besitzt
b) Ob alle Browser damit klar kommen, wenn a) theoretisch besteht
c) Ob man diese Komprimierung eher für verlinkte Dateien angedacht hat und nicht für die Seiten selbst

c) kann ich mir eher vorstellen. Dann verpackt httpd nämlich jede verlinkte Datei, bevor er sie zum Klient verschickt. Du klickst z.B. auf "meine_datei.exe" und bekommst stattdessen "meine_datei.exe.gz" runtergeladen.
a) und b) kann ich mir dagegen eher nicht vorstellen.

Bei busybox ist es leider öfters so, dass man die angekündigte Funktion zunächst falsch deutet und was vollkommen anders von ihr erwartet. Erst, wenn man die Funktion selbst ausprobiert hat, versteht man, was sie denn in Wirklichkeit tut.

Edit: a) gibt es doch tatsächlich: http://en.wikipedia.org/wiki/HTTP_compression (Komprimierung ist leider nur in englisch separat erklärt). Meine Frage b) bleibt aber immer noch offen: Ob alle Browser damit klar kommen. Also, der http-Header wird dadurch verändert...

MfG

 

[koyaanisqatsi]

Serverseitig wird, damit es den Sinn von Speicherplatzersparnis erfüllt, garnichts automatisch komprimiert.
Die Daten die ausgeliefert werden sollen sind vorher schon komprimiert worden. Also statisch, betoniert, archiviert, unveränderbar.
CGI Skripte lassen sich so nicht ausliefern. Das Favoritensymbol auch nicht.
Soweit ich dich verstanden habe, wie du es gerne hättest, und da hast du natürlich vollkommen recht, wird nichts komprimiert übertragen.
Diese Methode macht also nur Sinn für viel statischen Text der komprimiert wurde um physikalischen Speicher auf dem Webspace zu sparen, oder wozu soll dass sonst gut sein?

 

[hermann72pb]

Ich glaube, es geht eher um die Übertragung und um die HTTP-compression (s. meine Verlinkung oben). So wie du es dir vorstellst, ist es komplett anders rum. Du willst also alle Daten auf dem Server komprimiert (z.B. als gz-Dateien) vorliegen haben, um den Platz auf dem Server zu sparen. Und in deiner Wahrnehmung soll der httpd diese gz-Dateien entpacken und erst dann zum Server verschicken. So ist es aber bestimmt nicht gedacht.

Dein Vorhaben kann man anders realisieren, indem man komprimierte Dateisysteme verwendet (z.B. jffs). Es wird auf der Box zum Teil auch gemacht, um Platz im internen Flash zu sparen. Allerdings ist dafür nicht der httpd zuständig, sondern Dateisystem-Module. Die Komprimierung/Dekomprimierung erfolgt also eine Etage tiefer.

MfG

 

[koyaanisqatsi]

Oder es ist am End so, dass der httpd die index.html.gz ausliefert und der Firefox dekromprimiert das dann und ich bin zu doof dass zu merken?
Dann stellt sich mir laut dem Link von dir die Frage: Wie krieg ich dass denn raus, dass dem so ist?

 

[hermann72pb]

Wenn meine Vermutung stimmt, dann gilt Folgendes:
1. Du musst die Dateien nicht komprimieren. Sie liegen in gewöhnlicher (unkomprimierter) Form auf dem Server vor.
2. Wenn der Browser und der Server sich verständigt haben (so steht es auf der zitierten Wikipedia-Seite), dann kommt es zu einer komprimierten Übertragung
3. In erster Linie wirst du es natürlich nicht merken. Denn der Browser packt doch alles wieder aus, was der httpd verpackt hat.
4. http-Headers und Co. wirst du im Browser auch nicht merken. Auch nicht im Quelltext. Lediglich dürfte die Übertragung etwas schneller gehen oder weniger Traffik in Anspruch nehmen
5. Um die Wirkung der Option zu merken, solltest du Capture-Programme verwenden. Entweder die von AVM eingebaute Möglichkeit der Box oder gleich Wireshark. Dort kannst du die http-Headers sehen.
6. Alternativ würde es eventuell gehen, wenn du die Seiten mit wget aufrufst. Wenn ich mich richtig erinnere, gibt es bei wget die Möglichkeit auch die protokollspezifischen Sachen darstellen zu lassen. Es stellt sich allerdings die Frage, ob wget denn überhaupt die Komprimierung kann.

MfG

 

[koyaanisqatsi]

Danke, hab mal wieder was dazu gelernt, zum Beispiel wie man komprimierte Dateien komprimiert übertragen kann. lol
Und die Wirkung ist irgendwie offensichtlich, index.html.gz wird als Startdatei benutzt, anscheinend entpackt httpd die doch nicht sondern liefert sie so aus.

FREETZ_BUSYBOX_FEATURE_HTTPD_GZIP: x
x x
x Makes httpd send files using GZIP content encoding if the x
x client supports it and a pre-compressed <file>.gz exists.

Wird dann wohl eine .gz bevorzugt aber eine .html sollte auch vorhandensein.
Versucht man allerdings ein /index.html.gz in der Adressleiste wird sie als download angeboten?! (/index.html klappt obwohl die ja gar nicht da ist)

Eingabe in der Adresszeile von Firefox:

about:config

und nach accept suchen ergibt

network.http.accept-encoding;gzip, deflate

Ist zumindest ein Indiz für dass das, was du denkst und ich (mal wieder andersrum), simultan und Hand in Hand geht, ist doch hübsch.
(ich kann ihn ja spasseshalber mal löschen)
Gesagt getan, Ergebnis: 404 (not found) (Eine index.html.gz ist vorhanden, eine .html nicht)
Alle anderen Favoriten gehn noch. Wert wieder zurückkopiert und geht wieder. Klares Ergebnis.

 

[olistudent]

In der Busybox-Hilfe zu der Option steht doch genau beschrieben wie es funktioniert:

Makes httpd send files using GZIP content encoding if the client supports it and a pre-compressed <file>.gz exists.

Die komprimierte Datei wird anstatt der angefragten ausgeliefert. Durch den http-Header wird dem Browser mitgeteilt, dass es sich um gzip-Content handelt und dieser dekomprimiert den Content vor der Darstellung. Text und Javascript lassen sich natürlich hervorragend komprimieren. Vorteil ist die geringere Übertragungszeit und weniger Übertragungsvolumen. In welchen Einsatzbereichen das sinnvoll ist kann sich ja jeder selbst überlegen...

Gruß
Oliver

 

[koyaanisqatsi]

*.CSS kann auch ganz schön auftragen
Und wenn tatsächlich mal ein Browser ohne network.http.accept-encoding;gzip, deflate daherkommt gibts halt noch die index.html mit einem fallback in die Steinzeit.
index.html

<h1>Du kommst hier nicht rein!</h1>

Also, dankeschön nochmal, ja man könnte fast schon sagen, für diesen anregenden Chat.
Dieser mechanismus ist in der Tat sinnvoll einzusetzen, da er nicht, wie ich ursprünglich irrtümlich dachte, dekomprimiert und ausliefert, sondern nur entscheidet was er ausliefert und der Klient übernimmt dann gegebenenfalls das entpacken und entlastet so natürlich Bandbreite und Server.

Ist, würd ich mal sagen, verstanden worden.