[Next] [Previous] [Up] [Top] [Full Contents] [Search]

7. Entity

7.2 Entity Body

The entity-body (if any) sent with an HTTP/1.0 request or response is in a format and encoding defined by the Entity-Header fields.

Entity-Body	=	*OCTET
An entity-body is included with a request message only when the request method calls for one. This specification defines two request methods, "POST" and "PUT", that allow an entity-body. In general, the presence of an entity-body in a request is signaled by the inclusion of a Content-Length and/or Content-Transfer-Encoding header field in the request message headers.

Note
Most current implementations of the POST and PUT methods require a valid Content-Length header field. This can cause problems for some systems that do not know the size of the entity-body before transmission. Experimental implementations (and future versions of HTTP) may use a packetized Content-Transfer-Encoding to obviate the need for a Content-Length.

For response messages, whether or not an entity-body is included with a message is dependent on both the request method and the response code. All responses to the HEAD request method must not include a body, even though the presence of Content header fields may lead one to believe they should. Similarly, the responses "204 No Content", "304 Not Modified", and "406 None Acceptable" must not include a body.

7.2.1 Type

When an Entity-Body is included with a message, the data type of that body is determined via the header fields Content-Type, Content-Encoding, and Content-Transfer-Encoding. These define a three-layer, ordered encoding model:

entity-body <-
   Content-Transfer-Encoding( Content-Encoding( Content-Type ) )
The default for both encodings is none (i.e., the identity function). A Content-Type specifies the media type of the underlying data. A Content-Encoding may be used to indicate an additional encoding mechanism applied to the type (usually for the purpose of data compression) that is a property of the resource requested. A Content-Transfer-Encoding may be applied by a transport agent to ensure safe and/or proper transfer of the message. Note that the Content-Transfer-Encoding is a property of the message, not of the resource.

The Content-Type header field has no default value. If and only if the media type is not given by a Content-Type header (as is always the case for Simple-Response messages), the receiver may attempt to guess the media type via inspection of its content and/or the name extension(s) of the URL used to access the resource. If the media type remains unknown, the receiver should treat it as type "application/octet-stream".

7.2.2 Length

When an Entity-Body is included with a message, the length of that body may be determined in one of several ways. If a Content-Length header field is present, its value in bytes (number of octets) represents the length of the Entity-Body. Otherwise, the body length is determined by the Content-Type (for types with an explicit end-of-body delimiter), the Content-Transfer-Encoding (for packetized encodings), or the closing of the connection by the server. Note that the latter cannot be used to indicate the end of a request body, since it leaves no possibility for the server to send back a response.

Note
Some older servers supply an invalid Content-Length when sending a document that contains server-side includes dynamically inserted into the data stream. It must be emphasized that this will not be tolerated by future versions of HTTP. Unless the client knows that it is receiving a response from a compliant server, it should not depend on the Content-Length value being correct.

T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen - 12 MAR 95

[Next] [Previous] [Up] [Top] [Full Contents] [Search]

Generated with CERN WebMaker