Hallo, ich habe ein Problem mit dem Aufrufen einer einfachen HTTP-Internetseite an einigen mobilen Endgeräten. Auf einigen klappt es, bei anderen wiederum nicht und ich bekomme die Fehlermeldung: >Problem mit Datenverbindung >Der Server konnte nicht kommunizieren. Versuchen Sie es später erneut Ich habe keine Ahnung, warum einige Endgeräte das problemlos machen, andere wieder garnicht... Was inbsesondere nicht funktioniert ist die Verbindung weder mittels IPad noch mittels IPhone. Dort kommt die Fehlermeldung: >Safari kann die Seite "http://192...."; nicht öffnen, da dein iPad nicht >mit dem Internet verbunden ist Ist ja auch logisch... Das IPad ist ja mit dem ESP8266 Modul verbunden. Hat einer eine Idee, woran das liegen kann? PC gebunden wird die Seite übrigens auf allen bisher getesteten Brwosern problemlos dargestellt...
:
Verschoben durch User
ESP schrieb: >>Safari kann die Seite "http://192...."; nicht öffnen, da dein iPad nicht >mit dem > Internet verbunden ist Vielleicht traut ja Apple deren Nutzern die Benutzung einer IP gar nicht zu und Safari sucht statt dessen beim DNS nach dem Server mit dem Namen? kjghkfysd
Einige mobile Browser haben Proxies voreingestellt, die Webseiten vorkomprimieren sollen. Außerdem müsstest Du mal die URL ausschreiben, Vertipper passieren da sehr schnell.
Bei Android Geräten wen das WLAN im Stromsparmodi ist dann Trennen die die Verbindung wenn sie nicht ins internet kommen das wird aber nicht immer sofort angezeigt vielleicht hat Apple da was ähnliches eingebaut.
kjghkfysd schrieb: > Vielleicht traut ja Apple deren Nutzern die Benutzung einer IP gar nicht > zu und Safari sucht statt dessen beim DNS nach dem Server mit dem Namen? Das war sicher nur ironisch gemeint. > nicht öffnen, da dein iPad nicht mit dem Internet verbunden ist > Ist ja auch logisch... Das IPad ist ja mit dem ESP8266 Modul verbunden. Diese Aussagen beißen sich. Entweder ist das iPad mit einem Hotspot verbunden oder nicht. (siehe Symbol oben links) Und natürlich kann man auch IPs verwenden. Nur so ein IE von MS hält sich nicht an Standarts und sind deshalb nicht so gut fürs Internet geeignet. aws TZ
kjghkfysd schrieb: > Thomas Z. schrieb: >> Das war sicher nur ironisch gemeint. > > Nein. > > kjghkfysd ich habs gerade probiert - es geht mit IPs - warum auch nicht. Ich würde lieber nachsehen, ob das Teil wirklich verbunden ist und falls ja, welche Einstellungen der Hotspot liefert (auf das "i" rechts in den WLAN-Einstellungen klicken)
Thomas Z. schrieb: > Ich würde lieber nachsehen, ob das Teil wirklich verbunden und welche IP es bekommen hat.
Also es ist definitiv verbunden, es hat eine IP erhalten. Mag mirt ansonsten einer eine minimal-HTTP HEader+Body schreiben, die "eigentlich" funktionieren sollte?
ESP schrieb: > Also es ist definitiv verbunden, es hat eine IP erhalten. > > Mag mirt ansonsten einer eine minimal-HTTP HEader+Body schreiben, die > "eigentlich" funktionieren sollte? kommt der Request überhaupt beim ESP an? Kannst du nicht eine LED mal schalten, wenn eine Request empfangen wurde.
ESP schrieb: > Mag mirt ansonsten einer eine minimal-HTTP HEader+Body schreiben, die > "eigentlich" funktionieren sollte? Beispiel request:
1 | GET / HTTP/1.0 |
2 | Host: 192.... |
3 | Connection: Close |
Beispiel response:
1 | HTTP/1.0 200 OK |
2 | Connection: Close |
3 | Content-Length: 4 |
4 | |
5 | test |
Zeilenende "\r\n"
ESP schrieb: > was sind die "200 OK" ? Das ist eine verkürzte Schreibweise für 200x das Wort OK. Und bei "500 Internal Server Error" sind 500 Server kaputt. Es ist einfach der HTTP-Statuscode, der dem Client den Erfolg seiner Anfrage signalisiert. https://de.wikipedia.org/wiki/HTTP-Statuscode
ESP schrieb: > was sind die "200 OK" ? https://http.cat/200 K. L. schrieb: > "500 Internal Server Error" https://http.cat/500
Εrnst B. schrieb: > https://http.cat/200 > https://http.cat/500 :D Die anderen sind auch gut: https://http.cat/
Manche der "tollen" neuzeitlichen Internetzbrauser ignorieren doch einfach eine /etc/resolv.conf* und fragen direkt den "hartverdrahteten" DNS-Server. Das trifft wohl scheinbar neben den Androiden auch die Eierfoene. Mann soll der Werbung und dem Tracking nicht entkommen. Widerlich sowas. Da hat eine http://1.0.0.1:3333 natuerlich keine Chance. *) Wie auch immer die im betreffenden System gerade heisst.
hallo, wie muss man denn eine Seite aufbauen, die in mehreren Paketen geschickt wird? Ich stehe leider gerade vor dieser Aufgabe und einige Browser akzeptieren es. dass ich die Daten in Ruhe nacheinander schicke und bauen die Seite tatsächlih "von oben nach unten" hin langsam auf, andere (wieder Ihone) meckern. Wie teile ich dem System mit, dass da noch Daten kommen und der Seitenaufbau eben etwas dauert?
ESP schrieb: > wie muss man denn eine Seite aufbauen, die in mehreren Paketen geschickt > wird? Bei einer TCP Verbindung, wie sie von HTTP genutzt wird, weiss die Anwendung nichts mehr von den einzelnen Packeten, sondern sieht nur den Stream der Daten, welche diese beinhalten. Bei HTTP/1.0, falls kein Content-Length angegeben ist, ist das Dokument zuende, wenn die Verbindung geschlossen wird. Dies ist je nach client auch bei einem Timeout der Fall. Wenn man in HTTP/1.0 oder HTTP/1.1 den Content-Length header angibt, weiss der Browser, dass er alles bekommen hat, sobald er gleich viele Bytes vom HTTP Body gelesen hat, wie im Content-Length header stehen. Bei HTTP/1.1 gibt es noch den Transfer-Encoding: chunked header. Wenn man diesen setzt, gibt man beim message body in hex die länge des nächsten Chunks an daten, die man senden will, gefolgt von \r\n, gefolgt von den Daten des chuncks, gefolgt von \r\n, und dann nochmal das selbe mit dem nächsten chunck, usw. Und nach dem letzten chunk kommt noch einer mit länge 0, welcher das ende markiert. ESP schrieb: > andere (wieder Ihone) meckern. Was sagen sie denn? Es kann einen grosser Unterschied machen, jenachdem ob man es mit einem Timeout, einem Connection Reset, oder etwas anderem zutun hat. ESP schrieb: > Wie teile ich dem System mit, dass da noch Daten kommen und der > Seitenaufbau eben etwas dauert? Bei TCP gibt es TCP Keep-Alive, bei HTTP gibt es nichts brauchbares, dort muss man Daten liefern. HTTP bietet nur die möglichkeit, bevor man die eigentliche Response sendet, HTTP 100 Continue responses zu senden, wenn die Antwort Serverseitig erst langwierig berechnet werden muss, und der client kein Timeout bekommen soll. Wärend einer Response lange zu warten ist eigentlich nicht vorgesehen, aber die Timeouts sind nomalerweise sehr grosszügig.
D.h. ich könnte es vereinfachen, wenn ich mein Gerät einfach nur HTTP1.0 Antworten verschicken lasse, oder verschließe ich mich damit gegenüber HTTP1.1 Anfragen?
Eigentlich gibt es keinen Grund, HTTP/1.0 zu verwenden, denn bei HTTP/1.0 muss man entweder die Länge des Requests von anfang an kennen, oder man kann sich nichtmehr sicher sein, dass alles angekommen ist. HTTP/1.1 chuncked encoding ist nicht besonders Kompliziert, Beispiel response:
1 | HTTP/1.1 200 OK |
2 | Connection: Close |
3 | Transfer-Encoding: chunked |
4 | |
5 | 5 |
6 | Hello |
7 | 6 |
8 | World |
9 | 0 |
Der obere Request überträgt den folgenden Content:
1 | Hello World |
ESP schrieb: > D.h. ich könnte es vereinfachen, wenn ich mein Gerät einfach nur > HTTP1.0 Antworten verschicken lasse, oder verschließe ich mich damit > gegenüber HTTP1.1 Anfragen? Du darfst einen HTTP/1.1-Request immer mit einer HTTP/1.0-Response beantworten. Es gelten dann HTTP/1.0-Regeln und jeder Client kommt damit klar. Es gibt nach wie vor genug Software da draußen, die genau das tut.
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.