Hypertext Transfer Protocol -- HTTP/1.1

en · official · sha256:cbd318ecceb6c2b2d116caeb05db5a1a2baa77566ec37b2b9f1ffede2830839fEN

1.2 Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [34]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."

Ссылаются нормы: ComplianceIsPresumed, ConditionalComplianceIsTheMiddleTerm, MustFailureBeatsThePresumptionOfCompliance, MustFailureBeatsUnconditionalCompliance, MustLevelFailureDefeatsCompliance, MustLevelFailureDefeatsUnconditionalCompliance, ShouldFailureBeatsUnconditionalCompliance, ShouldLevelFailureDefeatsUnconditionalCompliance, UnconditionalComplianceIsPresumed, assert-h734d0ac981295cbc92d01df724f54592e39df2219e6169a472786f16d3762ce8

en · official · sha256:d5ea0dd2a4e8ce2ca6259254e77cf4f9f2cbe82678f2e5ddd6530426c343c7bcEN

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 Fielding, et al. Standards Track [Page 33]  RFC 2616 HTTP/1.1 June 1999 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. Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non- identity transfer-coding, the Content-Length MUST be ignored. When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.

Ссылаются нормы: AcceptingBodyWithoutLengthDeviates2616, GeneratingBothFieldsDeviates2616, IgnoringContentLengthConforms2616, IncludingBothFieldsDeviates2616, RespondingWithLengthErrorConforms2616, UsingContentLengthDeviates2616, assert-h01b6680978c1aa08171a982b3804a3f34f3ea8609de9d4b83869e6dd4e8bb42b, assert-h1557ecd6b6c50e71a28abdb08c0064a6339d98bf3d7d7696c777e8d95048a477, assert-h28e5ca025dcefa338d99bb6fe6588c20f034ad0d668683fd267f21547cbec4a4, assert-h3a9fabda849c79a524e0fbe6f5c32b0e0446fb394a48cc38e038976faa3ca32c, assert-h43f2a1821753cef9af81f6838ecde7c45d578998d2415522aa83625e295df88d, assert-h71461b4de6d46bccbb1d3dd40e69ebc909ccae51d39bce67fc33c3ba7b8e66e5, assert-h7a4c7a55225e2b6e89cfb91e5df47420042ee0b2894448faba13caa6064c4f46, assert-h7d03a8d1a1b998321b03935d9a419765553690730e356a44bbf03d5823a224c3