Hallo, ich habe das Problem bei meinem Webserver, daß manche Bilder zum Teil nicht angezeigt werden. Es liegt definitiv daran, daß der GET-Request vom Browser nicht an den AVR geschickt wird!!! Es sind nicht immer die selben Bilder und auch die Anzahl der fehlenden Bilder ist unterschiedlich. Ich versuche schon tagelang das Problem zu finden, aber ich komme nicht mehr weiter. Ich habe im Anhang das Problem etwas genauer geschildert. Ich hoffe jemand kann mir dabei weiter helfen. Gruß Martin
a) Testweise umstellen auf HTTP/1.0 (sosnt laufen mehrere GET Request über eine Verbindung was der Webserver u.U. nhct mag) b) Pufferüberlauf? Deshalb keine "großen" Bilder. c) Codierungsproblem? d) Fordere die Bilder doch mal manuell per Socket an und schau was da rauskommt.
Benedikt K. wrote:
> Hast du schon mal den Browser gewechselt?
ich habe es auch mit dem Netscape Navigator probiert, den ich auf dem PC
habe. Mit dem geht es allerdings überhaupt nicht, der findet den
Webserver mit der eingegebenen IP-Adresse nicht. Da ist irgendwas
verstellt...
Der Webserver sollte vor allem mit dem Internet Explorer funktionieren,
da ich weltweit von verschiedenen PC´s auf diesen zugreifen möchte.
Im Anhang nochmals der HTML-Code, diesmal als separate Datei.
Läubi .. wrote: > a) Testweise umstellen auf HTTP/1.0 (sosnt laufen mehrere GET Request > über eine Verbindung was der Webserver u.U. nhct mag) > b) Pufferüberlauf? Deshalb keine "großen" Bilder. > c) Codierungsproblem? > d) Fordere die Bilder doch mal manuell per Socket an und schau was da > rauskommt. a) wo kann ich das umstellen? Meinst Du die Antwort (HTTP-Header), die ich vom AVR sende: HTTP/1.1 200\r\nContent-Type: "text/html"... in "HTTP/1.0" ändern? b) das kann ich ausschließen. c) was meinst Du mit Codierungsprobleme? d) wie mache ich das? Wie schon gesagt, wenn ich im Internet-Expolorer die fehlenden Bilder mit Rechtsklick "Bild anzeigen" hole, dann werden die auch angezeigt.
zu 1) jepp! Und für Bilder sendest du doch hoffentlich nen anderen Content type?? zu 2) okay zu 3) char vs. unsigned char z.B. kann Probleme verursachen wenn man Binärdateien sendet zu 4) --> Google --> C+Sockets
Läubi .. wrote: > zu 1) jepp! Und für Bilder sendest du doch hoffentlich nen anderen > Content type?? > zu 2) okay > zu 3) char vs. unsigned char z.B. kann Probleme verursachen wenn man > Binärdateien sendet > zu 4) --> Google --> C+Sockets 1) es gibt bei mir folgende Unterscheidungen, je nach Dateityp im HTML-Header: PROGMEM char FLASH_WEB_HEADER_HTM[] = { "text/html" }; PROGMEM char FLASH_WEB_HEADER_JPG[] = { "image/jpeg" }; PROGMEM char FLASH_WEB_HEADER_BMP[] = { "image/bmp" }; PROGMEM char FLASH_WEB_HEADER_GIF[] = { "image/gif" }; 3) ich verwende für die Strings üblicherweise unsigned char. Aber das dürfte dem AVR doch egal sein, weil er die Daten nur durchschleift und nicht bearbeitet. 4) ich wede es mal probieren, aber vermutlich verstehe ich nur Bahnhof...
Benötigt Java (www.java.com). Dann in der Konsole aufrufen: JAVA -jar testclient.jar http://mikrocontroller.net Alternativ noch umleiten in eine Datei: JAVA -jar testclient.jar http://mikrocontroller.net > output.txt Das gibt dir dan die Sachen aus welche auch dein "Browser" empfangen müßte... oder einen Fehler :) Mußt mikrocontroller.net natürlich durch die IP deines Servers erseten.
Angehängte Dateien:
-
Java-Console.jpg
35 KB
Läubi .. wrote: > Benötigt Java (www.java.com). > > Dann in der Konsole aufrufen: > JAVA -jar testclient.jar http://mikrocontroller.net > > Alternativ noch umleiten in eine Datei: > JAVA -jar testclient.jar http://mikrocontroller.net > output.txt > > > Das gibt dir dan die Sachen aus welche auch dein "Browser" empfangen > müßte... oder einen Fehler :) > Mußt mikrocontroller.net natürlich durch die IP deines Servers erseten. Java hab ich gerade installiert. Und auch Deine jar-Datei downgeloaded. Wie ich jetzt weiter vorgehen muß, ist mir nicht ganz klar. Ich habe mal die jar-Datei doppel-geklickt, aber es tut sich nicht viel. Konsole? Meinst Du die, die man beim Rechtsklick auf das Symbol unten anklicken kann (siehe Bild)? Den Durchblick habe ich leider nicht so besonders...
ich habe nun mal bei "start" => "ausführen" folgendes eingegeben: JAVA -jar c:\testclient.jar http://192.168.178.21 > c:\output.txt Es erscheint kurz ein Fenster, das aber wieder zu geht. Wenn ich es mit der Stop-Taste anhalte, dann stehen dort Inhalte meiner HTML´s. Aber es ist schwierig, die Stop-Taste zum richtigen Zeitpunkt zu drücken. Was muß ich machen, daß das Fenster offen bleibt? Die von mir angegebene Datei c:\output.txt wird übrigens nicht erzeugt.
Läubi .. wrote: > bei ausführen 'cmd' eingeben Ich habe nun die Seiten aufgerufen, bei der die Sache mit den Bildern kommen sollte: JAVA -jar c:\testclient.jar http://192.168.178.21/grafik.htm?stockwerk=2 > c:\output.txt jetzt hat es geklappt. Vielen Dank für den Tipp! Das output-File sieht genau so aus wie die HTML-Datei, die der Webserver gesendet hat. Und nun??? Übrigens: Die Sache mit "HTTP/1.0" geht nicht. Da gehen selbst die HTML-Seiten nicht mehr vernünftig (Frames, ...). Bilder gehen überhaupt nicht mehr.
ruf mal ein Bild ab (umleiten per > test.jpg) und schau dann ob es richtig ankommt (also vieleicht mal in der Bildbearbeitung öffnen). >Übrigens: Die Sache mit "HTTP/1.0" geht nicht. Da gehen selbst die >HTML-Seiten nicht mehr vernünftig (Frames, ...). Bilder gehen überhaupt >nicht mehr. Sehr komisch, was für nen Webserver benuzt du den?
Läubi .. wrote: > ruf mal ein Bild ab (umleiten per > test.jpg) und schau dann ob es > richtig ankommt (also vieleicht mal in der Bildbearbeitung öffnen). hab ich mit einem GIF gemacht (siehe Anhang). Dateigröße von Original auf SD-Karte ist identisch mit dem Output-File. Aber das Output-Bild geht nicht. Der Anfang der Datei ist identisch, dann kommt nur Mist bei der Output-Datei. Aber als ich die Bild-Datei mit dem Browser angefordert habe, wurde dieses dort korrekt angezeigt. Komisch... > Sehr komisch, was für nen Webserver benuzt du den? Marke Eigenbau. ATMega128 + XPORT Direkt+. Ich sende die Bilder 1:1 an den XPORT. Der XPORT macht TCPIP draus. Ich habe mal mit Wireshark geschaut, was unterschiedlich ist, wenn ich die Bilder nicht vom Webserver nehme, sondern von meiner Homepage: Werden die Bilder von der Homepage geholt, dann läuft das irgendwie parallel. Während die HTML-Datei vom Webserver geholt wird, werden parallel dazu schon die GET´s für die Bilder von der Homepage ausgegeben. Wenn alles im Webserver ist (HTML und Bilder), dann wird erst das HTML komplett geholt und anschließend die Bilder mit GET angefordert. Leider halt nicht von allen, die sich im HTML befinden. Wenn die Bilder von der Homepage kommen, dann sehe ich die Bilddaten im Datenstream irgendwie nicht. Da kommen kaum Daten von meiner Homepage. Die Bilddaten fangen ja mit "GIF89a" an, den String hab ich nicht entdeckt. Entweder fängt die Winshark nicht ein oder es ist irgendwie komprimiert.
> Aber als ich die Bild-Datei mit dem Browser > angefordert habe, wurde dieses dort korrekt angezeigt. Komisch... Evtl. spielt dir der Browser-Cache einen Streich.. ;-) > Die Bilddaten fangen ja mit "GIF89a" an, den String hab ich nicht > entdeckt. Entweder fängt die Winshark nicht ein oder es ist irgendwie > komprimiert. ..sind die Daten nicht Base64 (oder wie das nochmal hieß..) codiert?
Das parrallele Abrufen ist "normal" siehe: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html Martin M. wrote: > Wenn alles im Webserver ist (HTML und Bilder), dann wird erst das HTML > komplett geholt und anschließend die Bilder mit GET angefordert. Leider > halt nicht von allen, die sich im HTML befinden. Sende im Header mal explizit bei jeder Anfrage
1 | Connection: close |
zu senden. Bei Tests mit dem Browser ist das immer sone Sache --> Stichwort Cache
Das Problem mit dem nicht darstellbaren Bild liegt vermutlich an der Console... Sorry daran hatte ich nicht gedacht. Im Anhang mal ein erweitertes Programm. Aufruf: java -jar testclient.jar test.jpg test2.jpg Vergleicht zwei Dateien Byteweise und gibt die Unterschiede aus java -jar testclient.jar http://test.de/bild.jpg Lädt die Datei und speichert sie unter dem angegebenem Dateinamen byte genau ab, zeigt zudem Header informationen des Servers an.
den Cache hatte ich bereits ausgeschaltet. Somit holt der Browser jedesmal die Bilder vom Webserver. Das mit dem erweiterten Programm teste ich morgen Abend mal aus. Vielen Dank. Ich melde mich dann morgen Abend wieder.
Jetzt hab ich die neue JAR-Datei ausprobiert. Beim Holen der Datei vom Webserver gibt es folgende Statusmeldung: Connect... Encoding: null Type: image/gif Length: 9916 === Header fields === null: [HTTP/1.1 200] CONTENT-LENGTH: [9916] Content-Type: [image/gif] Connection: [close] Read... Done! Sieht doch gut aus, oder? Wenn ich die Originaldatei mit der empfangenen vom Webserver vergleiche, dann gibt es keine Fehlermeldung bezüglich Unterschiede: Datei 1: C:\fehler\output.gif 9916bytes Datei 2: C:\fehler\sd_karte.gif 9916bytes Ist auch im grünen Bereich.... Das Problem ist ja nicht, daß die Bilder falsch übertragen werden, die auf der Seite nicht angezeigt werden. Sondern der GET-Request kommt nicht vom Browser von den fehlenden Bildern. Somit werden die Daten der fehlenden Bilder auch nicht vom Webserver gesendet. Das "Connection: close" hab ich übrigens schon immer so drin. Hast Du nun noch ne Idee, was man machen könnte?
Also das sieht soweit okay aus. Ich würde dann das Problem mal im Bereich des Browsers suchen. Hast du ne möglichkeit alle Request an den Webserver zusätzlich per RS232 an den PC zu senden oder sonstwie zu loggen? Ich bin erstmal beim Sport melde mich vorraussichtlich so gegen halb 11 nochmal, werde dann die Sotware so erweitern das die auch ne Website anzeigen kann, vieleicht bringt das Klarheit.
ich kann mittels Schieberegister- und Gattergrab die Quelle für den USB-Anschluß auf der Platine umschalten. Ich kann dann z.B. die TX- oder RX-Signale vom XPORT auf der USB-Schnittstelle ausgeben und mit dem PC aufzeichnen. Allerdings muß ich hierbei die Geschwindigkeit zwischen XPORT und AVR reduzieren, denn da fahre ich derzeit über 230 kBit/s. Ist aber kein riesiges Problem. Ich kann z.B. mit 57,6 arbeiten. Dann geht halt alles etwas langsamer. Das wäre super, wenn Du da ne Möglichkeit hättest.
Sonst wenn du noch etwas Ram frei hast mach dir nen Ringpuffer für 10 Anfragen (get reicht denke ich), und schreib den Puffer raus wenn man ne spezielle Seite abruft (log.txt) oder so. Gff ist auch ne SoftUART ne Option, würde zumindest helfen von "Protokoll unabhängiger" Seite die Sache zu betrachten. Neue Version im Anhang: Doppelklick oder Aufruf via commandozeile ohne Parameter startet den Minibrowser. Aber nicht zuviel erwarten der kann nur HTML kein JavaSkript/Cookoies, CSS nur eingeschränkt etc. ;) Hier noch ne Vermutung da ich den XPORT nicht kenne: ggf erlaubt dieser nur eine begrenzte Anzahl verbindungen, durch dein close zwingst du aber den Browser mehrere zu öffnen... Versuchs mal mit 'Keep-Alive' anstelle von 'close' du müßtest dann über eine Verbindung nur mehrere Request abarbeiten, vieleicht machst du das aber sowieso schon wie gesagt ich weiß nicht wie das mit dem XPORT abläuft.
Läubi .. wrote: > Sonst wenn du noch etwas Ram frei hast mach dir nen Ringpuffer für 10 > Anfragen (get reicht denke ich), und schreib den Puffer raus wenn man ne > spezielle Seite abruft (log.txt) oder so. Gff ist auch ne SoftUART ne > Option, würde zumindest helfen von "Protokoll unabhängiger" Seite die > Sache zu betrachten. das ist ne gute Idee. > Neue Version im Anhang: > Doppelklick oder Aufruf via commandozeile ohne Parameter startet den > Minibrowser. Aber nicht zuviel erwarten der kann nur HTML kein > JavaSkript/Cookoies, CSS nur eingeschränkt etc. ;) nicht schlecht! Der Browser ist echt gut geworden. Werde später mal meinen Webserver testen. Bin gerade nicht in meinem "Bastelzimmer". > Hier noch ne Vermutung da ich den XPORT nicht kenne: > ggf erlaubt dieser nur eine begrenzte Anzahl verbindungen, durch dein > close zwingst du aber den Browser mehrere zu öffnen... > Versuchs mal mit 'Keep-Alive' anstelle von 'close' du müßtest dann über > eine Verbindung nur mehrere Request abarbeiten, vieleicht machst du das > aber sowieso schon wie gesagt ich weiß nicht wie das mit dem XPORT > abläuft. Der XPORT hat einen Webserver integriert, aber dann muß man die Internetseiten mit JAVA machen, wenn man über die Schnittstelle mit dem AVR Daten austauschen möchte. Das ist mir zu aufwändig, mich da einzuarbeiten. Daher nutze ich die Webserver-Funktionalität des XPORT nicht. Die Daten vom AVR werden nur 1:1 durchgeschleift. C kann ich einigermaßen programmieren (wenn auch nicht perfekt), aber es ist für mich einfacher, die HTML-Seiten je nach Randbedingung im AVR aufzubauen. Der AVR kann nur 1 Connection handeln, so habe ich das zumindest programmiert. Wie soll ich das trennen mit mehreren Kanälen? Ich sende doch nur die Daten auf einen GET-Request. Ich wüßte nicht, wie ich das machen sollte, wenn es da mehrere GET-Requests parallel geben würde. Wo muß ich das "keep alive" senden? Nur bei den Bildern oder auch beim HTML-File? Und wie wird die Verbindung dann am Ende geschlossen? Müßte ich nach der Übertragung ein "close" irgendwie übertragen? Ich weiß, daß meine Lösung des Webservers vielleicht nicht gerade die beste ist, aber für meine Software-Kenntnisse ist er gar nicht so schlecht geworden. Ich kann den Stand der Rolläden abfragen (oben, unten) und kann übers Internet die Rolläden bedienen, wenn ich mal nicht zu Hause bin. Es wäre halt gut, wenn die Bilder auch auf dem Webserver wären. Wenn ich diese auf meine Homepage "auslagere" ist das etwas "primitiv". Man kann zwar auch Bilder auf dem XPORT Direct+ ablegen, aber wenn man die Serverfunktionalität deaktiviert, dann kann man nicht mehr auf diese zugreifen. Heißt: wenn ich die HTML´s vom AVR sende, dann müssen auch die Bilder von AVR gesendet werden. Ne Unterscheidungsmöglichkeit gibt es da laut Hersteller nicht.
Im Header statt connection: close connection: keep-alive Das hat zur Folge das der Browser eine Verbindung aufbaut, einen Request absendet (header endet ganz normal) aber Verbindung wird nicht geschlossen. Du sendest dem Brwoser die Datei, hierbei ist aber Content-Length ein Plicht - Feld (logisch sonst weiß der Bowser nicht wo die eine Datei endet und die andere aufhört), auf der noch offenen Verbindung sendet der Brwoser dann weitere Requests die du wiedrum beantwortest, bis der Server die verbindung schließt weil er alles geladen hat. Dies signalisiert er dir in der Art das er seinerseits mit dem lezten Request ein "Connection: close" im Header sendet. Du als server hast natürlich auch jederzeit die Möglichkeit zu sagen: Schluß ich mag nicht mehr, du DARFST aber jederzeit die Verbindung trozdem offen lassen auch wenn der Browser sagt er macht zu also wenn mans nicht zu genau nimmt kann man IMMER keep-alive senden, die Gegenstelle wird dann von sichaus die Verbindung schließen ;) Falls man (z.B. bei einer dynamischen Website) nicht von anfang an weiß wie groß die ist gibt es die Möglichkeit des "chuncked encodings". Das Problem könnte jezt folgendes sein wenn du NICHT erlaubst die Verbindung weiter zu benutzen: - Der Brwoser holt sich die HTML Seite - findet X Bilder - Versucht das erste zu laden --> du sagst er darf die Verbindung nicht weiterverwenden. - deshalb wird versucht eine zweite/dritte/vierte/Xte Verbindung aufzubauen, der XPORT stellt fest das schon eine offen ist und weisst die Verbindungsanforderung zurück und dein Brwoser bricht das laden aller weiteren Bilder ab da er denkt der Server sei nicht verfügbar.
Ich habe die Kommunikatuion zwischen AVR und XPORT auf 115200 Baud herunter gesetzt und die Daten aufgezeichnet. Die Daten mit close mit dem HTML mit mehreren Bildern: close_gesendet.txt close_empfangen.txt Aber ich habe die beiden Dateien nicht bei einer Aktion aufgezeichnet, sondern nacheinander. Es kann sein, daß bei den beiden Tests unterschiedliche Bilder nicht angezeigt wurden. Läubi .. wrote: > Im Header statt > connection: close > connection: keep-alive habe ich gemacht, aber das Ganze wird noch schlimmer. Selbst bei einem HTML mit einem einzigen Bild gibt es Probleme. Das Bild wird nicht angezeigt. keep_alive_gesendet.txt keep_alive_empfangen.txt => Es kommt kein GET für das Bild!!! Mit close wird das Bild problemlos angezeigt. Und wenn ich eine Seite mit dem Internet-Explorer aufrufe, blockiert der mir dauerhaft die Verbindung zum Webserver und mit Deinem testclient.jar geht dann nichts mehr.... Das mit der Längenangabe ist kein Problem. Bei den Bildern erhalte ich die Info beim Auslesen der SD-Karte. Die HTML´s bastle ich im externen RAM zusammen und frage vor dem Senden die Länge mit strlen() ab.
Nachtrag: das mit der genannten Seite mit dem einen Bild geht definitiv nie (Bild wird nie angezeigt): rolladen.jpg 8.244 Bytes Bei der Startseite ist auch ein Bild drauf. Dieses wird ab und zu mit Deinem Mini-Browser angezeigt, manchmal aber nicht: logo.gif 3.257 Bytes Eventuell gibt es da auch noch einen Zusammenhang mit der Bildgröße und/ oder HTML-Größe. Ich habe mal das rolladen.jpg auf 694 Bytes verkleinert. Wird aber trotzdem nicht angezeigt.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.