Valid HTTP response headers valid without transfer-encoding and content length?

Question

Is the HTTP response header (e.g. below) legal even if it doesn't have Content-Length or Transfer-Encoding?

- 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 

I expected to see Content-Length or Transfer-Encoding, but none of them exist.

I read HTTP-RFC, but I'm still not sure.

@CodeCaster, I read the RFC section 4.4, but it is still not clear, as you can see, the response header is used to return the json stream, therefore:

• section 4.4, rule 1 defines it MUST NOT include the body of the message, it does not seem to be relevant to my case.
• section 4.4, rule 4, is not sure about this, but since I do not see "multipart / byteranges" in the response header - does this mean that this rule does not apply to me?
• section 4.4, rule 5, this is mostly incomprehensible to me, since the title is "Connection: close", is this connected?

So, any further comments?

Answer 1

Yes this is true. There are five ways to determine the length of a message:

RFC 2616 Section 4.4. Message Length :

Message transmission length is the length of the message body as it appears in the message; that is, after they were applied. When the message body is included in the message, the carry length of this body is determined by one of the following (in order of priority):

• Any response message that “SHOULD NOT” include the message body (such as 1xx, 204, and 304 responses, and any response to a HEAD request) always ends with the first empty line after the header fields, regardless of the object’s header fields present in the message.

• If the Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transmission length is determined using the "packet" transmission encoding (section 3.6) if the message is not completed by closing the connection.

• If the Content-Length header field (section 14.13) is present, its decimal value in OCTET represents both the length of the object and the Transfer length. The Content-Length header field SHOULD NOT be sent if the two lengths are different (that is, if the transfer-encoding header field). If the message is received as with the Transfer-Encoding header field and the Content-Length header field, the latter MUST be ignored.

• If the message uses the media type "multipart / byteranges" and the transmission length is not specified otherwise, the limiting media type determines the transmission length. This media type [M] UST is NOT used if the sender does not know that the receiver can analyze it; the presence of a Range header with several bytes in the request - range specifiers from client 1.1 imply that the client can analyze multipart / byteranges.

  Range header can be redirected by proxy 1.0, which multipart / byteranges does not understand; in this case, the server MUST split the message using the methods defined in clauses 1.3 or 5 of this section.

• The server closes the connection. (Closing a connection cannot be used to indicate the end of the request body, as it will not leave the server unable to send a response.)