| The lax implementation of the content length strategy.
This strategy conforms to the entity transfer rules outlined in
Section 4.4,
Section 3.6,
Section 14.41
and Section 14.13
of RFC 2616, but is lenient
about unsupported transfer codecs and malformed content-length headers.
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 ransfer-length is not
otherwise specified, then this self- elimiting media type defines the transfer-length.
This media type UST NOT be used unless the sender knows that the recipient can arse it; the
presence in a request of a Range header with ultiple byte- range specifiers from a 1.1
client implies that the lient 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.)
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body
MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1
compliant. If a request contains a message-body and a Content-Length is not given, the
server SHOULD respond with 400 (bad request) if it cannot determine the length of the
message, or with 411 (length required) if it wishes to insist on receiving a valid
Content-Length.
All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding
(section 3.6), thus allowing this mechanism to be used for messages when the message
length cannot be determined in advance.
3.6 Transfer Codings
Transfer-coding values are used to indicate an encoding transformation that
has been, can be, or may need to be applied to an entity-body in order to ensure
"safe transport" through the network. This differs from a content coding in that
the transfer-coding is a property of the message, not of the original entity.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )
Parameters are in the form of attribute/value pairs.
parameter = attribute "=" value
attribute = token
value = token | quoted-string
All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in
the TE header field (section 14.39) and in the Transfer-Encoding header field (section 14.41).
Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST
include "chunked", unless the message is terminated by closing the connection. When the
"chunked" transfer-coding is used, it MUST be the last transfer-coding applied to the
message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a
message-body. These rules allow the recipient to determine the transfer-length of the
message (section 4.4).
14.41 Transfer-Encoding
The Transfer-Encoding general-header field indicates what (if any) type of transformation has
been applied to the message body in order to safely transfer it between the sender and the
recipient. This differs from the content-coding in that the transfer-coding is a property of
the message, not of the entity.
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
If multiple encodings have been applied to an entity, the transfer- codings MUST be listed in
the order in which they were applied. Additional information about the encoding parameters
MAY be provided by other entity-header fields not defined by this specification.
14.13 Content-Length
The Content-Length entity-header field indicates the size of the entity-body, in decimal
number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of
the entity-body that would have been sent had the request been a GET.
Content-Length = "Content-Length" ":" 1*DIGIT
Applications SHOULD use this field to indicate the transfer-length of the message-body,
unless this is prohibited by the rules in section 4.4.
author:
Oleg Kalnichevski
version:
$Revision: 576073 $
since:
4.0 | 