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)?
In so ziemlich jedem Browser (F12 drücken). Oder Fiddler, Wireshark,... Ach ja: Google wurde auch schon erfunden.
Wenn du im Browser auf "Seitenquelltext anzeigen" gehst, müsstest du eigentlich sehen können, was der Browser gekriegt hat.
Firefox und das Web Developer Plugin zeigen Dir alle Infos z.B. Headers an.
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/
Hat sich geklärt: Nach dem Header mus zwei mal CRLF stehen ... mannomann ...
1 | HTTP/1.0 200 OK<CRLF> |
2 | Server: WebScrab/1.0<CRLF> |
3 | Date: Sat, 02 Jan 2014 21:14:30 GMT<CRLF> |
4 | Content-Length: 14002<CRLF> |
5 | Connection: close<CRLF> |
6 | Content-Type: text/html<CRLF> |
7 | <CRLF> |
8 | <html><head></head><body><img src='data:image/jpg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a ... |
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)!
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.