Re: HTTP/1.1 response with no headers?

On Wed, 10 Jul 2002, Joe Orton wrote:

> Just curious - if a client receives the response:
> 
>   HTTP/1.1 200 OK<CRLF>
>   <CRLF>
> 
> should it be treated as a response with no message body, or a message
> body delimited by an EOF?

IMO, RFC 2616 explicitly says that the above response body is
determined by the server closing the connection (EOF), provided this
response is for a request method that implies entity (message body)
presence (see 10.2.1 200 OK). A message body may be of zero length, of
course:

   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 
     [ does not apply ]

   2.If a Transfer-Encoding header field (section 14.41) is present
     [ does not apply ]

   3.If a Content-Length header field (section 14.13) is present,
     [ does not apply ]

   4.If the message uses the media type "multipart/byteranges",
     [ does not apply ]

   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.)
     [ applies! ]

If this is a response for, say, HEAD request, then (1) above applies.

> Mozilla seems to opt for the latter; as far as I could work out from
> 2616 the former is correct - a request may or may not include a message
> body... the presence of a message body is signalled by a
> Transfer-Encoding or Content-Length header (or implicit for HEAD, 204,
> 304 etc)... so no T-E or C-L implies no message body.

Not sure what you are saying here, but no T-E or C-L does not imply no
message body. The above headers are from a response, not from a
request.

For requests, it looks like RFC 2616 implies that a request for which
items 1-4 do not apply is invalid. This is natural not only because
there is no way for the server to respond if EOF is detected (there
may be a way if half-closed or non-TCP connections are considered),
but because it is a bad idea for the server to act on a possibly
truncated request. For example, a POST depositing "$10000" may result
in a "$10" deposit...

$0.02,

Alex.

Received on Thursday, 11 July 2002 11:55:28 UTC