Ist "Content-Length" oder "Chunked Transfer-Encoding" ein Muss für die HTTP-Anfrage?

Question

Kann mir jemand über diese Inhaltslänge oder Transfer-Encoding sagen: "Chunked" ist ein Muss für HTTP-Anfrage? Ich benutze C++, um einen http-Server zu schreiben.

Die HTTP-Antwort kann close Socket verwenden, um die Länge des Nachrichtentexts zu kennen. Aber wie wäre es mit einer Anfrage?

Ich habe RFC2616 über http 1.1 überprüft, aber ich bin nicht klar genug darüber.

Meine Frage ist, wenn eine HTTP-Anfrage ohne "Content-Length" oder "Chunked Transfer-Encoding" gesendet, wie könnte ich "WSARecv" verwenden, um die Länge des Nachrichtentextes zu kennen, für den Fall, dass ich WSARecv verwende Alle Header und Netstream endet mit "\ r \ n \ r \ n" zufällig, ich bekomme nicht die Länge des Nachrichtentextes. Wenn ich eine WSARecv erneut ausliege, kann es ewig dauern, weil keine Daten mehr vorhanden sind. Wenn ich "WSARecv" nicht mehr ausliege, bekomme ich möglicherweise den Nachrichtentext nicht nach.

Oder vielleicht die "Content-Length" und "Chunked Transfer-Encoding" ist ein Muss für HTTP-Anfrage? Client sollte einen von ihnen setzen, um die Länge der Nachricht zu teilen?

Answer 1

Wenn Sie nicht über eine Transfer-Encoding oder Content-Length geben Sie dann die Anforderung (oder Antwort) ist implizit eine variable Länge Request/Response und der einzige Weg, um das Ende des Körpers zu signalisieren, ist die Verbindung zum Herunterfahren (und umgekehrt erkennen die Herunterfahren/eof im Empfänger).

Dies bedeutet, dass diese Art von Anforderung/Antwort auch Connection: close

Wenn Sie die Umsetzung HTTP1.1 dann müssen Sie unterstützen alle drei Übertragungsmethoden implizit ist.

Als ich meinen HTTP-Server schrieb, abstrahierte ich das Konzept eines "Anfrage-Streams" vom Konzept eines "Verbindungs-Streams". Der "Anfrage-Stream" ist polymorph und unterstützt das Lesen von "EOF". Es gibt keinen Grund, dass Sie nicht auch eine Methode "read_chunk" haben könnten. Im Falle einer nicht-chunked Anfrage könnte dies einfach bis EOF gelesen werden. Diese

mir erlaubt die gleichzeitige Ausführung mehrerer Anfragen auf derselben Verbindung zu implementieren (aber es gibt einige Schmu, um sicherzustellen, dass die Antworten in der richtigen Reihenfolge wiederkommen!)

Answer 2

RFC 2616 ist überholt.

Die Antwort ist in https://greenbytes.de/tech/webdav/rfc7230.html#header.content-length.