nicht angemeldet
Moin dedlfix,
Es geht nicht um die Weiterverarbeitung sondern erst einmal nur um das Auslesen der POST-Daten. In welche Struktur du sie dann für die Weiterverarbeitung bringst, ist völlig nebensächlich für die Frage, ob man sich auf die Content-Lenght-Angabe verlassen soll und ob man sie überhaupt braucht. Die einfachste Lösung ist - egal ob der Content-Lenght-Header vom Client mitgesendet und/oder richtig ist - eine Schleife, die bis zum Datenende Häppchen liest (und diese dann in irgendeine Struktur oder auch nur aneinander in ein Byte-Array oder String oder sonstwas hängt).
Das ist nicht so einfach. Du liest keine Datei aus, es gibt kein EOF, du befindest dich in einem Netzwerk-Kontext. Woran erkennst du das "Datenende?" Wenn du liest, bis nichts mehr kommt, wirst du entweder bis zum Timeout blockieren oder du wirst nicht alle Daten lesen.
Deshalb gibt es bei HTTP halt entweder den Content-Length-Header oder ein Transfer-Encoding wie chunked. Bei Content-Length ist klar, wieviel gelesen werden muss, da es durch den Client bekannt gegeben wird. Bei Transfer-Encoding: chunked werden die Daten häppchenweise übertragen, und es wird jedesmal die Länge des Datums mitgegeben:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25
This is the data in the first chunk
1C
and this is the second one
3
con
8
sequence
0
Die HTTP-RFC sagt dazu:
[...] The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. [...]
Absichern gegen falsche Längen kann man sich relativ einfach: für eine zu große Angabe gibt es einen Receive-Timeout. Und für eine zu kurze Angabe, ja mei, dann ist halt der nächste Request syntaktisch falsch.
LG,
CK