HTTP Webserver für mobile Endgeräte

Einige mobile Browser haben Proxies voreingestellt, die Webseiten 
vorkomprimieren sollen.

Außerdem müsstest Du mal die URL ausschreiben, Vertipper passieren da 
sehr schnell.

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)

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/

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.

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.