Tach zusammen,
Ich stehe mal wieder auf dem Schlauch und benötige Hilfe von Euch.
Ich möchte vom Browser aus Befehle an den MC senden und auch Messwerte
im Browser sehen.
Erstmal alles im internen Netzwerk hinter der Fritzbox.
Wenn ich z.B. die Ziel IP Adresse und über (IP:5000/?red=1) in die
Adressleiste eingebe, kommt auch die GET Methode über RS232 an den
Mikrocontroller an:
HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
r-AA: Mozilla/5òGET /?red=1 HTTP/1.1
Host: 192.168.178.34:5000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101
Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Im Browser steht dann in der Statusleiste ...Warten auf 192.168....
Soweit so gut. wenn ich nun einen Standart Response Header
zurückschicke,
passiert im Browser aber nichts mehr. Es scheint, das die Verbindung
nicht beendet wird.
Hier mein Response Header:
UART1_Write_Text("HTTP/1.1 200 OK");
UART1_Write_Text("\r\n");
UART1_Write_Text("Content-Type: text/html");
UART1_Write_Text("\r\n");
UART1_Write_Text("Connection: close");
UART1_Write_Text("\r\n");
UART1_Write_Text("");
UART1_Write_Text("\r\n");
Habe schon viel gesucht, aber es erschließt sich mir einfach nicht.
Ich habe da noch ein Grundsatzdefizit, wer kann mich mal einnorden?
1.) Was mache ich falsch, bzw. was muss als Response geschickt werden?
2.) Das alles passiert über Port 5000, ist das bei Port 80 auch so?
3.) Wie sollte ich die GET Methode im MC am besten auswerten oder was
ist wichtig?
4.) Ich würde auch später gern eine Passwortabfrage machen, bevor ich
Messwerte sehen kann
oder Befehle schicken kann. Wie relisiert man sowas am einfachsten.
Mit POST oder ähnlich?
MfG
Carsten
Ob Port 5000 oder 80 ist wurscht. Dieses sind Schrottdaten: > r-AA: Mozilla/5òGET /?red=1 HTTP/1.1 Kann nicht ausgewertet werden. Es hat so auszusehen: > GET /?red=1 HTTP/1.1 In einer einzelnen abgeschlossenen Zeile Und ja, für Loginvorgänge solltest du POST verwenden, sonst werden deine Zugangsdaten höchstvermutlich in Logfiles und Proxies gespeichert. Stichworte für Google: "HTTP Spezifikation" und/oder "Representational State Transfer"
Hi! Danke, ware wirklicht Schrottdaten. Lag an einer komischen Drahtverbindung zum RS232 Sniffer. Hier nochmal: GET /?red=1 HTTP/1.1 Host: 192.168.178.34:5000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Das sende ich dann unmittelbar zurück: HTTP/1.0 200 OK Content-Type: text/html Connection: close Funst trotzdem nicht! Carsten
C. L. schrieb: > passiert im Browser aber nichts mehr. Es scheint, das die Verbindung > nicht beendet wird. > > Hier mein Response Header: > > UART1_Write_Text("HTTP/1.1 200 OK"); > UART1_Write_Text("\r\n"); > UART1_Write_Text("Content-Type: text/html"); > UART1_Write_Text("\r\n"); > UART1_Write_Text("Connection: close"); > UART1_Write_Text("\r\n"); > UART1_Write_Text(""); > UART1_Write_Text("\r\n"); Schon probiert mal zumindest ein Zeichen in den Body zu machen (zweitletzte Zeile mit "0" statt "")?
Ich schrieb: > Schon probiert mal zumindest ein Zeichen in den Body zu machen > (zweitletzte Zeile mit "0" statt "")? Klappt auch nicht..... :-( Ist denn der Ablauf richtig oder fehlt da noch was? Der eine sagt Content Länge muss sein, der andere sagt kann.... Ich habe keinen Plan Carsten
Bei compressed-Inhalten solltest du die Content-Length angeben. Ansonsten wartet er bis zum Timeout.
Wenn du "Content-Type: text/html", dann solltest du auch eine HTML Seite
ausliefern.
> Der eine sagt Content Länge muss sein
Muss nicht, wenn die Verbindung sofort geschlossen wird.
Wird aber das "Connection: keep-alive" Verfahren verwendet, dann gehts
nicht ohne. Dieses macht aber meist auf den Zwergenrechnern keinen
wirklichen Sinn.
Also:
Request trudelt vom Client ein.
Request auswerten
Header senden
Body senden
Kleines Zeitchen warten, damit auch alle Daten raus sind
Verbindung schließen.
C. L. schrieb: > Hier mein Response Header: > > UART1_Write_Text("HTTP/1.1 200 OK"); > UART1_Write_Text("\r\n"); > UART1_Write_Text("Content-Type: text/html"); > UART1_Write_Text("\r\n"); > UART1_Write_Text("Connection: close"); > UART1_Write_Text("\r\n"); > UART1_Write_Text(""); > UART1_Write_Text("\r\n"); Und schon falsch. Sowohl beim HTTP-Request als auch beim Response muß zwischen Message- Header und Message-Body (beim Request: POST Daten) eine Leerzeile sein. Also eher so:
1 | UART1_Write_Text("HTTP/1.1 200 OK\r\n"); |
2 | UART1_Write_Text("Content-Type: text/html\r\n"); |
3 | UART1_Write_Text("Connection: close\r\n"); |
4 | UART1_Write_Text("\r\n"); |
5 | UART1_Write_Text("Hier könnte Ihre Message stehen\r\n"); |
6 | /* und jetzt wirklich die Verbindung schließen */
|
Einen Content-Length Header mitzuschicken ist insofern sinnvoll, als dann der Client weiß wann er alle Daten hat. Oh und wenn du schon "text/html" ankündigst, dann solltest du das auch schicken. Sonst nimm "text/plain". Maßgeblich sind die RFCs für das HTTP Protokoll. Lesen! https://www.ietf.org/rfc/rfc2616.txt https://www.ietf.org/rfc/rfc2068.txt (der Vorgänger) https://www.ietf.org/rfc/rfc1945.txt (HTTP/1.0, reicht oft auch)
Hi! Danke für die Antworten... Axel S. schrieb: > Und schon falsch. Hmmm, das hatte ich aus dem Beispielcode für Arduino von der NetIO APP von David Eickhoff. Es stand so auch auf der Arduino Hompage. => Komisch! Axel S. schrieb: > /* und jetzt wirklich die Verbindung schließen */ Ahhha! Was heisst das genau? Muss ich mein Wlan Modul (WIZ610) nun anweisen (habe ich probiert, geht nicht), die TCP Verbindung zu schließen? Dachte das wäre über "Connection:Close" im ResponseHeader gemacht. Zumindest reagiert der Browser mit diesem Code schonmal und zeigt jetzt an, das er auf Daten wartet: UART1_Write_Text("HTTP/1.1 200 OK\r\n"); UART1_Write_Text("Content-Type: text/html\r\n"); UART1_Write_Text("Connection: close\r\n"); UART1_Write_Text("\r\n"); UART1_Write_Text("Hier könnte Ihre Message stehen\r\n"); /* und jetzt wirklich die Verbindung schließen */ Breche ich jetzt die Verbindung im Browser ab, scheint alles wieder ok zu sein. Was kann der Haken sein, warum es nicht klappt? Helft mir nochmal weiter,bitte! Gruß Carsten
Wenn man die Contentlaenge schon weiss, sollte man sie auch verwenden.
C. L. schrieb: > die TCP Verbindung zu schließen? Dachte das wäre über "Connection:Close" > im ResponseHeader gemacht. Connection: Close Ist Teil des HTTP, nicht des TCP/IP. Du musst also deiner Funle sagen, dass sie die TCP Verbindung schließt. Wie? KA, kenne deine Funke nicht.
HTTP/1.0 nehmen und/oder noch ein \r\n zum Schluß schicken
Hi! Soooo, die Mischung aus Euren Antworten hat erstmal einen Teilerfolg gebracht. Es funktioniert jetzt (fast) erwartungsgemäß. Das liegt aber an meinen Programm und das gehe ich gleich an. Hier die Lösung: //GET kommt GET /?red=1 HTTP/1.1 Host: 192.168.178.34:5000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive // Response mit HTML Close HTTP/1.0 200 OK Content-Type: text/plain Connection: close Hier könnte Ihre Message stehen // Und nun noch der TCP close vom Wlanmodul mit Feedback. <WC><S> Danke, Gruß Carsten
C. L. schrieb: > Axel S. schrieb: >> /* und jetzt wirklich die Verbindung schließen */ > Ahhha! Was heisst das genau? > Muss ich mein Wlan Modul (WIZ610) nun anweisen > (habe ich probiert, geht nicht), > die TCP Verbindung zu schließen? Dachte das wäre über "Connection:Close" > im ResponseHeader gemacht. Nö. Der HTTP-Header sagt dem Client nur, daß der Server die Verbindung schließen wird, sobald das Response raus ist. Machen muß der Server das aber trotzdem noch. Denn der Browser weiß ja weder, wie lang die Response sein wird. Noch darf er selber die Verbindung schließen. Lies doch einfach mal wenigstens einen der verlinkten RFCs. > Zumindest reagiert der Browser mit diesem Code schonmal und zeigt jetzt > an, das er auf Daten wartet Das war zu erwarten. Ohne die Leerzeile nach den HTTP-Headern wartet der Browser immer weiter ob da noch ein Header kommt oder vielleicht endlich mal ein Message-Body. > Breche ich jetzt die Verbindung im Browser ab, scheint alles wieder ok > zu sein. Was kann der Haken sein, warum es nicht klappt? Du mußt die TCP-Verbindung auch schließen. Wie das geht, hängt von deinem WLAN Modul ab.
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.