HTTP response headers valid with no Transfer-Encoding and Content-Length?

Question

Is a HTTP response Header (like the one below) legal even if if does not contain 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 either Content-Length or Transfer-Encoding, but none of them exist.

I read the HTTP-RFC but am still unsure.

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

• section 4.4, rule 1 defines MUST NOT include a message-body, does not seem to apply to my case.
• section 4.4, rule 4, not sure about this, but since I do not see "multipart/byteranges" in the response header - does it mean this rule is not applicable for me?
• section 4.4 rule 5, this is mostly unclear to me since the header actual contain "Connection : close", is it related?

So, any further comments?

Answer 1

Yes, it is valid. There are five ways to determine the message length:

RFC 2616 Section 4.4. Message Length:

The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):

1. Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.

2. If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.

3. If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

4. If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self- delimiting media type defines the transfer-length. This media type [M]UST NOT be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple byte- range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.

  A range header might be forwarded by a 1.0 proxy that does not

   understand multipart/byteranges; in this case the server MUST
   delimit the message using methods defined in items 1,3 or 5 of
   this section.

5. By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.)