Ich bastele hier an einem kleinen Tool zur Überwachung von
Digital-Signage-Stationen. Es handelt sich dabei um einen kleinen
Webserver, der bei Connect durch einen Browser einen Screenshot macht,
diesen verkleinert und dann eingebettet in einen HTML-"Rumpf"
zurücksendet.
Bitte keine Diskussion, dass ich ja VNC nehmen könnte. Das wäre
unpraktisch, weil ich ein ganzes Übersichts-Panel machen will, übers
Intranet erreichbar ohne Installationen bei den Mitarbeitern. Livebilder
sind nicht nötig, Screenshots aller 10 Sekunden genügen.
Dabei habe ich das Problem, dass wenn ich die vom Webserver lokal
angelegte Temp-Datei öffne genau das sehe, was ich erwarte.
Im Browser (sowohl lokal als auch remote) wird dagegen der
HTML-Sourcecode als Text angezeigt ... und ich weiss nicht wo ich nach
dem Fehler suchen soll. Könnte höchstens etwas im HTTP-Haeder nicht
stimmen ... aber was?
Mit welchem Tool bekomme ich denn den gesamten HTTP-Datenverkehr
angezeigt (mögl. Mac)?
Frank schrieb:> Mit welchem Tool bekomme ich denn den gesamten HTTP-Datenverkehr> angezeigt (mögl. Mac)?
Wireshark ist quasi das Standard-Tool dafür. Gibt es auch für Mac OS X:
http://www.wireshark.org/
Frank schrieb:> mannomann ...
Ja genau, man o man... WENN man schon für sich in Anspruch nimmt
etwas, was es tausendfach bewährt mit jahrelanger Entwicklung/Erfahrung
schon fertig gibt nochmal selber zu implementieren und dann auch noch
möglicherweise für Dritte im Auftrag sollte man doch wenigstens die
Basics beherrschen oder sich anlesen (es steht ja sogar in Wikipedia
falls einem das einschlägige RFC zu "trocken" ist...).
Frank schrieb:> Nach dem Header mus zwei mal CRLF stehen
Nein muss es nicht, der Header wird durch eine leere Zeile abgeschlossen
(wie dein Beispiel auch zeigt)!
Karl Heinz schrieb:> Wenn du im Browser auf "Seitenquelltext anzeigen" gehst, müsstest du> eigentlich sehen können, was der Browser gekriegt hat.
Natürlich nicht. Da ist nur der HTML-Teil zu sehen. Hier interessant ist
aber der HTTP-Dialog.
Läubi .. schrieb:> Ja genau, man o man... WENN man schon für sich in Anspruch nimmt> etwas, was es tausendfach bewährt mit jahrelanger Entwicklung/Erfahrung> schon fertig gibt nochmal selber zu implementieren und dann auch noch
Es gibt bereits ein bedienfreies Hintergrundtool, was ohne Passwort und
mit einstellbarer Skalierung per HTTP Screenshots liefert? Ohne .NET,
ohne Java und ohne 1000 weitere (überflüssige) Funktionen? Dann wäre ich
dankar für einen Link.
> möglicherweise für Dritte (=für Geld) sollte man doch wenigstens die> Basics beherrschen oder sich anlesen (es steht ja sogar in Wikipedia> falls einem das einschlägige RFC zu "trocken" ist...).
Also - das "mannomann" bezog sich natürlich auf meine eigene
Unaufmerksamkeit und die damit verschwendete Zeit. D.h. diese Tatsache
hat sich jetzt tief in mich eingebrannt - so ganz verschwendet war sie
also nicht.
>Nein muss es nicht, der Header wird durch eine leere Zeile abgeschlossen>(wie dein Beispiel auch zeigt)!
Dumme Frage: Wie, wenn nicht durch durch zwei CRLF macht man sonst eine
leere Zeile?
Frank schrieb:> Es gibt bereits ein bedienfreies Hintergrundtool, was ohne Passwort und> mit einstellbarer Skalierung per HTTP
Die Anwendung vielleicht nicht, aber es gibt fertige HTTP Server
welche per definierter Schnittstelle oder sogar Skriptsprache dir die
Umsetzung der Anwendung ermöglichen. Ob du da C, C++, C#, Java, ...
bevorzugst weiß ich nicht, ich denke mal es geht dir da um den Client.
Frank schrieb:> Dumme Frage: Wie, wenn nicht durch durch zwei CRLF macht man sonst eine> leere Zeile?
JEDE Headerzeile wird durch ein CRLF abgeschlossen, es wird nicht
dadurch eine neue begonnen, enthält die Zeile nichts außer CRLF so ist
diese "leer" im Sinne des Protokolls.
d.h. Sinnigerweise würde man sich eine Funktion putHeaderLine o.ä.
definieren und die dann z.B. so aufrufen:
1
putHeaderLine("HTTP/1.0 200 OK");
2
putHeaderLine("Server: WebScrab/1.0");
3
putHeaderLine("");
Da gibt es keine "zwei" CRLF, das zwei aufeinaderfolgen ist nur der
Tatsache geschuldet, dass du eine leere Zeile hast.
Frank schrieb:> 1000 weitere (überflüssige) Funktionen
HTTP hat noch "1000 weitere" Kleinigkeiten die man beachten sollte wenn
man nicht immer wieder über solche Fallstricke stolpern will und sich
wundern warum das nicht oder nur manchmal nicht läuft. Daher würde ich
da immer eine erprobte und möglichst vollständige Implementierung
vorziehen, du rennst sonst nur den Fehlerchen hinterher.
Läubi .. schrieb:> Die Anwendung vielleicht nicht, aber es gibt fertige HTTP Server> welche per definierter Schnittstelle oder sogar Skriptsprache dir die
Ich wollt jetzt nicht auf jenden Clienten ein komplettes Softwarepaket
ala Apache aufspielen. Was ich gemacht habe, ist eine eigenständige
kleine Anwendung mit einem offenen TCP-Socket, die bei Connect einen
in HTTP verpackten Schreenshot zurücksendet - nicht mehr und nicht
weniger.
Geschrieben in Realbasic, compiliert ca. 5 MB, unabhängig von anderen
Libs - dazu gleich noch aus dem selben Sourcecode eine Mac- und
Linux-Version. Nix Script-Gefrickel, sorry ...
Luxil schrieb:> Firefox und das Web Developer Plugin zeigen Dir alle Infos z.B. Headers> an.
Haette ich auch so vorgeschlagen, viel einfacher zu nutzen als zB.
Wireshark, und wenn es "nur" um HTTP geht auch ausreichend fuer die
meisten Faelle.
Frank schrieb:> Realbasic
Auch dafür gibt es schon vorgefertigte HTTP Server Module.
Es bleiben sicher noch genug Herausforderungen, z.B. das ganze gege
Missbrauch abzusichern.
Mladen G. schrieb:> Luxil schrieb:>> Firefox und das Web Developer Plugin zeigen Dir alle Infos z.B. Headers>> an.>> Haette ich auch so vorgeschlagen, viel einfacher zu nutzen als zB.> Wireshark, und wenn es "nur" um HTTP geht auch ausreichend fuer die> meisten Faelle.
Das funktioniert aber nur eingeschränkt wenn das HTTP Protokoll an sich
verkorkst ist.
Läubi .. schrieb:> Frank schrieb:>> Realbasic>> Auch dafür gibt es schon vorgefertigte HTTP Server Module.
Ja, ich habe auf das mitgelieferte Beispiel "webserver.rb" aufgebaut,
was seltsamerweise genau den oben genannten Fehler beinhaltet, sowohl in
der RB 2011 als auch in dem jüngsten Xojo-Beispiel. Aber egal, das ist
jetzt behoben.
> Es bleiben sicher noch genug Herausforderungen, z.B. das ganze gegen> Missbrauch abzusichern.
Die von mir nun gefertigte Variante reagiert nur auf GET-Requests für
"image.html?X" mit einem Screenshot. URL-Parameter werden - wenn es sich
um Zahlen 1-10 handelt - ausschließlich als Skalierung 1/X
interpretiert, alles Andere wird verworfen.
Auch die Abfragefrequenz ist auf 1 pro 15 Sekunden von der selben
IP-Adresse begrenzt, ansonsten wird bereits die Socket-Verbindung
gekappt. Da das Tool darüber hinaus ausschließlich fürs betriebliche
Intranet vorgesehen ist, glaube ich, alles Erforderliche getan zu haben.
