HTTP-Antwortheader sind gültig ohne Transfer-Encoding und Content-Length?

Question

Ist ein HTTP-Antwort-Header (wie der unten) zulässig, auch wenn er keine Content-Length- oder Transfer-Encoding-Funktion enthält?

- Http: Response, HTTP/1.1, Status: Ok, URL: /AAA/B.json 
    ProtocolVersion: HTTP/1.1 
    StatusCode: 200, Ok 
    Reason: OK 
    Expires: Fri, 05 Oct 2012 01:41:30 GMT 
    Date: Fri, 05 Oct 2012 01:40:46 GMT 
    Vary: Accept-Encoding 
    Accept-Ranges: bytes 
    Cache-Control: public, max-age=43 
    Server: Noelios-Restlet-Engine/1.1.10 
    ContentType: application/json;charset=UTF-8 
    ContentEncoding: gzip 
    Connection: close 
    X-Served-By: 85.111 
    HeaderEnd: CRLF 

ich erwartet hatte entweder Content-Length oder Transfer-Encoding, aber keiner von ihnen existieren, um zu sehen.

Ich habe den HTTP-RFC gelesen, bin aber immer noch unsicher.

@CodeCaster, habe ich gelesen RFC Abschnitt 4.4, aber ich bin immer noch nicht klar, wie man sehen kann, wird die Antwort-Header verwendet, um einen json Strom zurückzukehren, so:

• Abschnitt 4.4, Regel 1 definiert MUSS KEINE Nachricht enthalten, scheint nicht auf meinen Fall zutreffen.
• Abschnitt 4.4, Regel 4, bin mir nicht sicher, aber da ich "multipart/byteranges" im Antwortheader nicht sehe - bedeutet das, dass diese Regel nicht für mich gilt?
• Abschnitt 4.4 Regel 5, das ist mir meistens unklar, da der Header tatsächlich "Verbindung: schließen" enthält, ist es verwandt?

Also, weitere Kommentare?

Answer 1

Ja, es ist gültig. Es gibt fünf Möglichkeiten, um die Nachrichtenlänge zu bestimmen:

RFC 2616 Section 4.4. Message Length:

Der Transfer-Länge einer Nachricht ist die Länge der Nachricht Körper als es erscheint in der Nachricht; das heißt, nach irgendwelchen Transfer-Codierungen wurden angewendet. Wenn eine Nachricht über den Körper mit einer Nachricht enthalten ist, wird die Übertragungs Länge dieses Körpers durch eine der folgenden (in der Reihenfolge der Priorität) bestimmt:

1. Nachricht keine Antwort, die „darf nicht“ umfassen ein Nachrichtentext (wie als die 1xx, 204 und 304 Antworten und jede Antwort auf eine HEAD Anfrage) wird immer durch die erste leere Zeile nach den Header-Felder, unabhängig von den Entity-Header-Feldern in der Botschaft.

2. Wenn ein Transfer-Encoding-Header-Feld (Abschnitt 14.41) vorhanden ist, und hat einen anderen Wert als „Identität“, so ist die Übertragungslänge ist definiert durch die Verwendung der „segmentierte“ Transfer-Codierung (Abschnitt 3.6), , es sei denn, die Nachricht wird durch Schließen der Verbindung beendet.

3. Wenn ein Content-Length-Header-Feld (Abschnitt 14.13) vorhanden ist, dessen Dezimalwert in Oktetts repräsentiert sowohl die Entität-Länge und der Übertragungslänge. Das Content-Length-Header-Feld darf NICHT gesendet werden, wenn diese beiden Längen unterschiedlich sind (d. H. Wenn ein Transfer-Encoding Header-Feld vorhanden ist). Wenn eine Nachricht mit einem Transfer-Encoding-Header-Feld und einem Content-Length-Header-Feld empfangen wird, MUSS letztere ignoriert werden.

4. Wenn die Nachricht verwendet den Medientyp „multipart/byteranges“ und die Übertragungslänge nicht anders angegeben ist, dann definiert dieser selbstbegrenze Medienart die Übertragungslänge. Dieser Medientyp [M] UST NICHT verwendet werden, es sei denn der Absender weiß, dass der Empfänger es analysieren kann; Die Anwesenheit in einer Anforderung eines Range-Headers mit mehreren byte- Bereichsspezifizierern von einem 1.1-Client impliziert, dass der Client multipart/byterange-Antworten parsen kann.

   Ein Bereichsheader kann von einem 1.0-Proxy weitergeleitet werden, der nicht versteht, multipart/byterangs; In diesem Fall MUSS der Server die Nachricht unter Verwendung der in den Punkten 1,3 oder 5 von in diesem Abschnitt definierten Methoden abgrenzen.

5. Durch den Server, der die Verbindung schließt. (Schließen der Verbindung kann nicht verwendet werden, um das Ende einer Anfrage Körper, um anzuzeigen, da diese keine Möglichkeit für den Server eine Antwort hinterlassen würde zurück zu senden.)