Текст порождён из пакета паком law.verb.ru@0.7.0, а не написан рядом с ним: рассинхронизировать изложение с нормами нельзя по построению. Пробелов тотальности нет: каждый узел пакета получил изложение.

Ревью-документ: пакет «ietf.http_framing» 0.1.0

Дисклеймер. Это не официальный текст закона и не юридическое заключение. Документ порождён детерминированной проекцией (ступень 2: используются морфологические формы меток; нормативные позиции duty, liberty, power и immunity, толкования и изменения редакций отображаются явно; имена аргументов отношений называются русским словарём, а переменные обозначаются краткими именами по типу) формализации в контролируемый русский язык и не имеет самостоятельной силы: при расхождении этого текста и семантики программы дефектом является шаблон вербализации, а не программа.

Вербализация: law.verb.ru@0.7.0 · язык ru-KZ · semantic hash программы sha256:19090f384145db5471641abca9888e553f09c72457adc5eef819c0f902e88c51

Источники

RFC2616

Источник «RFC2616».

Идентификатор: urn:ietf:clir:http-framing#RFC2616

RFC7230

Источник «RFC7230».

Идентификатор: urn:ietf:clir:http-framing#RFC7230

RFC9112

Источник «RFC9112».

Идентификатор: urn:ietf:clir:http-framing#RFC9112

RFC2616_EN

Издание «RFC2616_EN» источника «RFC2616», язык en.

Состояние adopted: 1999-06-01.

Состояние in_force: с «1999-06-01» и далее.

Идентификатор: urn:ietf:clir:http-framing#RFC2616_EN

RFC7230_EN

Издание «RFC7230_EN» источника «RFC7230», язык en.

Состояние adopted: 2014-06-01.

Состояние in_force: с «2014-06-01» и далее.

Идентификатор: urn:ietf:clir:http-framing#RFC7230_EN

RFC9112_EN

Издание «RFC9112_EN» источника «RFC9112», язык en.

Состояние adopted: 2022-06-01.

Состояние in_force: с «2022-06-01» и далее.

Идентификатор: urn:ietf:clir:http-framing#RFC9112_EN

Закреплённые публикации

RFC2616_EN_TEXT

Закреплённая публикация издания «RFC2616_EN»: https://www.rfc-editor.org/rfc/rfc2616.txt.

Хэш документа: sha256:10211d2885196b97b1c78e1672f3f68ae97c294596ef2b7fd890cbd30a3427bf; тип text/plain; charset=utf-8; получен 2026-08-30T11:00:00Z.

Идентификатор: urn:ietf:clir:http-framing#RFC2616_EN_TEXT

RFC7230_EN_TEXT

Закреплённая публикация издания «RFC7230_EN»: https://www.rfc-editor.org/rfc/rfc7230.txt.

Хэш документа: sha256:c7fdc8bebdf1f8195f731592c47f5ea822b489436fd905b01b55ef531fca4120; тип text/plain; charset=utf-8; получен 2026-08-30T11:00:00Z.

Идентификатор: urn:ietf:clir:http-framing#RFC7230_EN_TEXT

RFC9112_EN_TEXT

Закреплённая публикация издания «RFC9112_EN»: https://www.rfc-editor.org/rfc/rfc9112.txt.

Хэш документа: sha256:e4f426bac6206b67fdf9e0da826154f70588db2133a0a86b15cde4ff725d8937; тип text/plain; charset=utf-8; получен 2026-08-30T11:00:00Z.

Идентификатор: urn:ietf:clir:http-framing#RFC9112_EN_TEXT

Фрагменты источников

RFC2616_S1_2

Фрагмент section/1_2 издания «RFC2616_EN».

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."

Хэш официального текста: sha256:cbd318ecceb6c2b2d116caeb05db5a1a2baa77566ec37b2b9f1ffede2830839f.

Идентификатор: urn:ietf:clir:http-framing#RFC2616_S1_2

RFC2616_S4_4

Фрагмент section/4_4 издания «RFC2616_EN».

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.

Хэш официального текста: sha256:d5ea0dd2a4e8ce2ca6259254e77cf4f9f2cbe82678f2e5ddd6530426c343c7bc.

Идентификатор: urn:ietf:clir:http-framing#RFC2616_S4_4

RFC7230_S1_1

Фрагмент section/1_1 издания «RFC7230_EN».

1.1. Requirements Notation

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 [RFC2119].

Conformance criteria and considerations regarding error handling are defined in Section 2.5.

Хэш официального текста: sha256:48d3c2df23d66fff10dd5ac623a3a440749f20110a49e6ece036aa807c823cfc.

Идентификатор: urn:ietf:clir:http-framing#RFC7230_S1_1

RFC7230_S3_3_3

Фрагмент section/3_3_3 издания «RFC7230_EN».

3.3.3. Message Body Length

The length of a message body is determined by one of the following (in order of precedence):

Any response to a HEAD request and any response with a 1xx (Informational), 204 (No Content), or 304 (Not Modified) status code is always terminated by the first empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message body.

Any 2xx (Successful) response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes the header fields. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in such a message.

If a Transfer-Encoding header field is present and the chunked transfer coding (Section 4.1) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer coding indicates the data is complete.

If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.

If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.

If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and the recipient MUST treat it as an unrecoverable error. If this is a request message, the server MUST respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy, the proxy MUST close the connection to the server, discard the received response, and send a 502 (Bad

Fielding & Reschke Standards Track [Page 32] RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
   Gateway) response to the client.  If this is a response message
   received by a user agent, the user agent MUST close the
   connection to the server and discard the received response.
If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient times out before the indicated number of octets are received, the recipient MUST consider the message to be incomplete and close the connection.

If this is a request message and none of the above are true, then the message body length is zero (no message body is present).

Otherwise, this is a response message without a declared message body length, so the message body length is determined by the number of octets received prior to the server closing the connection.

Since there is no way to distinguish a successfully completed, close-delimited message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0.

A server MAY reject a request that contains a message body but not a Content-Length by responding with 411 (Length Required).

Unless a transfer coding other than chunked has been applied, a client that sends a request containing a message body SHOULD use a valid Content-Length header field if the message body length is known in advance, rather than the chunked transfer coding, since some existing services respond to chunked with a 411 (Length Required) status code even though they understand the chunked transfer coding. This is typically because such services are implemented via a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire request before processing.

A user agent that sends a request containing a message body MUST send a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.

If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that

Fielding & Reschke Standards Track [Page 33] RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014

data belongs as part of the prior response body, which might be the case if the prior message's Content-Length value is incorrect. A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning.

Хэш официального текста: sha256:46c66855bda647d16ada634829e2a4c958bb496498b12e90da87a555c8ee6d80.

Идентификатор: urn:ietf:clir:http-framing#RFC7230_S3_3_3

RFC9112_S1_1

Фрагмент section/1_1 издания «RFC9112_EN».

1.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Conformance criteria and considerations regarding error handling are defined in Section 2 of [HTTP].

Хэш официального текста: sha256:6dc47e04a3b0faee100bb908c2b01d555f9b02c189e1950fa381ab86b29abdea.

Идентификатор: urn:ietf:clir:http-framing#RFC9112_S1_1

RFC9112_S6_3

Фрагмент section/6_3 издания «RFC9112_EN».

6.3. Message Body Length

The length of a message body is determined by one of the following (in order of precedence):

Any response to a HEAD request and any response with a 1xx (Informational), 204 (No Content), or 304 (Not Modified) status code is always terminated by the first empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message body or trailer section.

Any 2xx (Successful) response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes the header fields. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in such a message.

If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 11.2) or response splitting (Section 11.1) and ought to be handled as an error. An intermediary that chooses to forward the message MUST first remove the received Content-Length field and process the Transfer-Encoding (as described below) prior to forwarding the message downstream.

If a Transfer-Encoding header field is present and the chunked transfer coding (Section 7.1) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer coding indicates the data is complete.

If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server.

If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.

If a message is received without Transfer-Encoding and with an invalid Content-Length header field, then the message framing is invalid and the recipient MUST treat it as an unrecoverable error, unless the field value can be successfully parsed as a comma-separated list (Section 5.6.1 of [HTTP]), all values in the list are valid, and all values in the list are the same (in which case, the message is processed with that single value used as the Content-Length field value). If the unrecoverable error is in a request message, the server MUST respond with a 400 (Bad Request) status code and then close the connection. If it is in a response message received by a proxy, the proxy MUST close the connection to the server, discard the received response, and send a 502 (Bad Gateway) response to the client. If it is in a response message received by a user agent, the user agent MUST close the connection to the server and discard the received response.

If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient times out before the indicated number of octets are received, the recipient MUST consider the message to be incomplete and close the connection.

If this is a request message and none of the above are true, then the message body length is zero (no message body is present).

Otherwise, this is a response message without a declared message body length, so the message body length is determined by the number of octets received prior to the server closing the connection.

Since there is no way to distinguish a successfully completed, close- delimited response message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0.
  |  *Note:* Request messages are never close-delimited because they
  |  are always explicitly framed by length or transfer coding, with
  |  the absence of both implying the request ends immediately after
  |  the header section.
A server MAY reject a request that contains a message body but not a Content-Length by responding with 411 (Length Required).

Unless a transfer coding other than chunked has been applied, a client that sends a request containing a message body SHOULD use a valid Content-Length header field if the message body length is known in advance, rather than the chunked transfer coding, since some existing services respond to chunked with a 411 (Length Required) status code even though they understand the chunked transfer coding. This is typically because such services are implemented via a gateway that requires a content length in advance of being called, and the server is unable or unwilling to buffer the entire request before processing.

A user agent that sends a request that contains a message body MUST send either a valid Content-Length header field or use the chunked transfer coding. A client MUST NOT use the chunked transfer coding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.

If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that data belongs as part of the prior message body, which might be the case if the prior message's Content-Length value is incorrect. A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning.

Хэш официального текста: sha256:3c4a2a30d78fbee9606692608f07b70173016a0194d9f916cdb1122102efe699.

Идентификатор: urn:ietf:clir:http-framing#RFC9112_S6_3

Ссылки на источники

RFC7230_OBSOLETES_RFC2616

Динамическая ссылка на «RFC2616» section/4_4: издание определяется на момент legal_time.

Идентификатор: urn:ietf:clir:http-framing#RFC7230_OBSOLETES_RFC2616

RFC9112_OBSOLETES_RFC7230

Динамическая ссылка на «RFC7230» section/3_3_3: издание определяется на момент legal_time.

Идентификатор: urn:ietf:clir:http-framing#RFC9112_OBSOLETES_RFC7230

Понятия

FramingRole

Понятие «FramingRole».

Идентификатор: urn:ietf:clir:http-framing#FramingRole

HttpMessage

Понятие «HttpMessage».

Идентификатор: urn:ietf:clir:http-framing#HttpMessage

Отношения и признаки

CL_IGNORED_ON_RECEIPT_2616

Отношение «CL_IGNORED_ON_RECEIPT_2616».

Идентификатор: urn:ietf:clir:http-framing#CL_IGNORED_ON_RECEIPT_2616

CL_NOT_SENT_WITH_TE_2616

Отношение «CL_NOT_SENT_WITH_TE_2616».

Идентификатор: urn:ietf:clir:http-framing#CL_NOT_SENT_WITH_TE_2616

Intermediary

Отношение «Intermediary».

Идентификатор: urn:ietf:clir:http-framing#Intermediary

MESSAGE_MUST_NOT_INCLUDE_BOTH_2616

Отношение «MESSAGE_MUST_NOT_INCLUDE_BOTH_2616».

Идентификатор: urn:ietf:clir:http-framing#MESSAGE_MUST_NOT_INCLUDE_BOTH_2616

REJECT_CONFLICTING_CL_7230

Отношение «REJECT_CONFLICTING_CL_7230».

Идентификатор: urn:ietf:clir:http-framing#REJECT_CONFLICTING_CL_7230

REMOVE_CL_AND_PROCESS_TE_9112

Отношение «REMOVE_CL_AND_PROCESS_TE_9112».

Идентификатор: urn:ietf:clir:http-framing#REMOVE_CL_AND_PROCESS_TE_9112

REMOVE_CL_BEFORE_FORWARDING_7230

Отношение «REMOVE_CL_BEFORE_FORWARDING_7230».

Идентификатор: urn:ietf:clir:http-framing#REMOVE_CL_BEFORE_FORWARDING_7230

RESPOND_400_OR_411_2616

Отношение «RESPOND_400_OR_411_2616».

Идентификатор: urn:ietf:clir:http-framing#RESPOND_400_OR_411_2616

RFC2616_DOCUMENT

Отношение «RFC2616_DOCUMENT».

Идентификатор: urn:ietf:clir:http-framing#RFC2616_DOCUMENT

RFC7230_DOCUMENT

Отношение «RFC7230_DOCUMENT».

Идентификатор: urn:ietf:clir:http-framing#RFC7230_DOCUMENT

RFC9112_DOCUMENT

Отношение «RFC9112_DOCUMENT».

Идентификатор: urn:ietf:clir:http-framing#RFC9112_DOCUMENT

Recipient

Отношение «Recipient».

Идентификатор: urn:ietf:clir:http-framing#Recipient

Sender

Отношение «Sender».

Идентификатор: urn:ietf:clir:http-framing#Sender

accepted_without_length

Отношение «accepted_without_length».

Аргументы: i: Implementation, m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#accepted_without_length

acts_as

Отношение «acts_as».

Аргументы: i: Implementation, played: FramingRole.

Идентификатор: urn:ietf:clir:http-framing#acts_as

carries_both_framing_fields

Отношение «carries_both_framing_fields».

Аргументы: m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#carries_both_framing_fields

compliant

Отношение «compliant».

Аргументы: i: Implementation.

Идентификатор: urn:ietf:clir:http-framing#compliant

conditionally_compliant

Отношение «conditionally_compliant».

Аргументы: i: Implementation.

Идентификатор: urn:ietf:clir:http-framing#conditionally_compliant

forwarded_downstream

Отношение «forwarded_downstream».

Аргументы: i: Implementation, m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#forwarded_downstream

generated_by

Отношение «generated_by».

Аргументы: m: HttpMessage, i: Implementation.

Идентификатор: urn:ietf:clir:http-framing#generated_by

has_content_length

Отношение «has_content_length».

Аргументы: m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#has_content_length

has_transfer_encoding

Отношение «has_transfer_encoding».

Аргументы: m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#has_transfer_encoding

ignored_content_length

Отношение «ignored_content_length».

Аргументы: i: Implementation, m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#ignored_content_length

kept_content_length_when_forwarding

Отношение «kept_content_length_when_forwarding».

Аргументы: i: Implementation, m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#kept_content_length_when_forwarding

multiple_conflicting_content_length

Отношение «multiple_conflicting_content_length».

Аргументы: m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#multiple_conflicting_content_length

processed_as_valid

Отношение «processed_as_valid».

Аргументы: i: Implementation, m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#processed_as_valid

received_by

Отношение «received_by».

Аргументы: m: HttpMessage, i: Implementation.

Идентификатор: urn:ietf:clir:http-framing#received_by

removed_content_length_before_forwarding

Отношение «removed_content_length_before_forwarding».

Аргументы: i: Implementation, m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#removed_content_length_before_forwarding

request_with_body_without_content_length

Отношение «request_with_body_without_content_length».

Аргументы: m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#request_with_body_without_content_length

responded_400_or_411

Отношение «responded_400_or_411».

Аргументы: i: Implementation, m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#responded_400_or_411

responded_bad_request

Отношение «responded_bad_request».

Аргументы: i: Implementation, m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#responded_bad_request

unconditionally_compliant

Отношение «unconditionally_compliant».

Аргументы: i: Implementation.

Идентификатор: urn:ietf:clir:http-framing#unconditionally_compliant

used_content_length

Отношение «used_content_length».

Аргументы: i: Implementation, m: HttpMessage.

Идентификатор: urn:ietf:clir:http-framing#used_content_length

Установленные факты

assert-1

Факт: «stated_in» («CL_NOT_SENT_WITH_TE_2616», «RFC2616_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-1 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

assert-10

Факт: «stated_in» («REJECT_CONFLICTING_CL_7230», «RFC7230_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-10 Анкер: urn:ietf:clir:http-framing#RFC7230_S3_3_3

assert-11

Факт: «keyword_written» («REMOVE_CL_BEFORE_FORWARDING_7230», «Must», «AllCapitals»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-11 Анкер: urn:ietf:clir:http-framing#RFC7230_S3_3_3

assert-12

Факт: «keyword_written» («REJECT_CONFLICTING_CL_7230», «Must», «AllCapitals»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-12 Анкер: urn:ietf:clir:http-framing#RFC7230_S3_3_3

assert-13

Факт: «stated_in» («REMOVE_CL_AND_PROCESS_TE_9112», «RFC9112_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-13 Анкер: urn:ietf:clir:http-framing#RFC9112_S6_3

assert-14

Факт: «keyword_written» («REMOVE_CL_AND_PROCESS_TE_9112», «Must», «AllCapitals»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-14 Анкер: urn:ietf:clir:http-framing#RFC9112_S6_3

assert-15

Факт: «adopted_bcp14» («RFC2616_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-15 Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2

assert-16

Факт: «adopted_bcp14» («RFC7230_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-16 Анкер: urn:ietf:clir:http-framing#RFC7230_S1_1

assert-17

Факт: «adopted_bcp14» («RFC9112_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-17 Анкер: urn:ietf:clir:http-framing#RFC9112_S1_1

assert-2

Факт: «stated_in» («CL_IGNORED_ON_RECEIPT_2616», «RFC2616_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-2 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

assert-3

Факт: «keyword_written» («CL_NOT_SENT_WITH_TE_2616», «MustNot», «AllCapitals»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-3 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

assert-4

Факт: «keyword_written» («CL_IGNORED_ON_RECEIPT_2616», «Must», «AllCapitals»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-4 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

assert-5

Факт: «stated_in» («MESSAGE_MUST_NOT_INCLUDE_BOTH_2616», «RFC2616_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-5 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

assert-6

Факт: «keyword_written» («MESSAGE_MUST_NOT_INCLUDE_BOTH_2616», «MustNot», «AllCapitals»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-6 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

assert-7

Факт: «stated_in» («RESPOND_400_OR_411_2616», «RFC2616_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-7 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

assert-8

Факт: «keyword_written» («RESPOND_400_OR_411_2616», «Should», «AllCapitals»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-8 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

assert-9

Факт: «stated_in» («REMOVE_CL_BEFORE_FORWARDING_7230», «RFC7230_DOCUMENT»).

Основание: source_asserted.

Идентификатор: urn:ietf:clir:http-framing#assert-9 Анкер: urn:ietf:clir:http-framing#RFC7230_S3_3_3

Правила

AcceptingBodyWithoutLengthDeviates2616

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «received_by» (m: H, i: I) и установлено, что «request_with_body_without_content_length» (m: H) и установлено, что «accepted_without_length» (i: I, m: H), то «behaviour_deviates» (I, «RESPOND_400_OR_411_2616»).

Идентификатор: urn:ietf:clir:http-framing#AcceptingBodyWithoutLengthDeviates2616 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

BothFramingFieldsPresent

Для HttpMessage H (v0).

Всегда, если установлено, что «has_transfer_encoding» (m: H) и установлено, что «has_content_length» (m: H), то «carries_both_framing_fields» (m: H).

Идентификатор: urn:ietf:clir:http-framing#BothFramingFieldsPresent

ComplianceIsPresumed

Для Implementation I (v0); Requirement R (v1).

По общему правилу, если установлено, что «absolute_requirement» (R) и установлено, что «subject_to» (I, R) и установлено, что «claims_conformance» (I, «RFC2616_DOCUMENT»), то «compliant» (i: I), — если не установлено иное.

Идентификатор: urn:ietf:clir:http-framing#ComplianceIsPresumed Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2

ConditionalComplianceIsTheMiddleTerm

Для Implementation I (v0).

По общему правилу, если установлено, что «compliant» (i: I) и установлено, что не «unconditionally_compliant» (i: I), то «conditionally_compliant» (i: I), — если не установлено иное.

Идентификатор: urn:ietf:clir:http-framing#ConditionalComplianceIsTheMiddleTerm Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2

ForwardingWithContentLengthDeviates7230

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «forwarded_downstream» (i: I, m: H) и установлено, что «kept_content_length_when_forwarding» (i: I, m: H) и установлено, что «carries_both_framing_fields» (m: H), то «behaviour_deviates» (I, «REMOVE_CL_BEFORE_FORWARDING_7230»).

Идентификатор: urn:ietf:clir:http-framing#ForwardingWithContentLengthDeviates7230 Анкер: urn:ietf:clir:http-framing#RFC7230_S3_3_3

ForwardingWithoutContentLengthConforms7230

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «removed_content_length_before_forwarding» (i: I, m: H) и установлено, что «forwarded_downstream» (i: I, m: H) и установлено, что «carries_both_framing_fields» (m: H), то «behaviour_conforms» (I, «REMOVE_CL_BEFORE_FORWARDING_7230»).

Идентификатор: urn:ietf:clir:http-framing#ForwardingWithoutContentLengthConforms7230 Анкер: urn:ietf:clir:http-framing#RFC7230_S3_3_3

GeneratingBothFieldsDeviates2616

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «acts_as» (i: I, played: «Sender») и установлено, что «generated_by» (m: H, i: I) и установлено, что «carries_both_framing_fields» (m: H), то «behaviour_deviates» (I, «CL_NOT_SENT_WITH_TE_2616»).

Идентификатор: urn:ietf:clir:http-framing#GeneratingBothFieldsDeviates2616 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

IgnoringContentLengthConforms2616

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «received_by» (m: H, i: I) и установлено, что «ignored_content_length» (i: I, m: H) и установлено, что «carries_both_framing_fields» (m: H), то «behaviour_conforms» (I, «CL_IGNORED_ON_RECEIPT_2616»).

Идентификатор: urn:ietf:clir:http-framing#IgnoringContentLengthConforms2616 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

IncludingBothFieldsDeviates2616

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «generated_by» (m: H, i: I) и установлено, что «carries_both_framing_fields» (m: H), то «behaviour_deviates» (I, «MESSAGE_MUST_NOT_INCLUDE_BOTH_2616»).

Идентификатор: urn:ietf:clir:http-framing#IncludingBothFieldsDeviates2616 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

IntermediaryForwardingWithContentLengthDeviates9112

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «forwarded_downstream» (i: I, m: H) и установлено, что «kept_content_length_when_forwarding» (i: I, m: H) и установлено, что «carries_both_framing_fields» (m: H) и установлено, что «acts_as» (i: I, played: «Intermediary»), то «behaviour_deviates» (I, «REMOVE_CL_AND_PROCESS_TE_9112»).

Идентификатор: urn:ietf:clir:http-framing#IntermediaryForwardingWithContentLengthDeviates9112 Анкер: urn:ietf:clir:http-framing#RFC9112_S6_3

IntermediaryRemovingContentLengthConforms9112

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «removed_content_length_before_forwarding» (i: I, m: H) и установлено, что «forwarded_downstream» (i: I, m: H) и установлено, что «carries_both_framing_fields» (m: H) и установлено, что «acts_as» (i: I, played: «Intermediary»), то «behaviour_conforms» (I, «REMOVE_CL_AND_PROCESS_TE_9112»).

Идентификатор: urn:ietf:clir:http-framing#IntermediaryRemovingContentLengthConforms9112 Анкер: urn:ietf:clir:http-framing#RFC9112_S6_3

MustLevelFailureDefeatsCompliance

Для Implementation I (v0); Requirement R (v1).

По общему правилу, если установлено, что «behaviour_deviates» (I, R) и установлено, что «absolute_requirement» (R) и установлено, что «subject_to» (I, R) и установлено, что «claims_conformance» (I, «RFC2616_DOCUMENT»), то не имеет места, что «compliant» (i: I), — если не установлено иное.

Идентификатор: urn:ietf:clir:http-framing#MustLevelFailureDefeatsCompliance Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2

MustLevelFailureDefeatsUnconditionalCompliance

Для Implementation I (v0); Requirement R (v1).

По общему правилу, если установлено, что «behaviour_deviates» (I, R) и установлено, что «absolute_requirement» (R) и установлено, что «subject_to» (I, R) и установлено, что «claims_conformance» (I, «RFC2616_DOCUMENT»), то не имеет места, что «unconditionally_compliant» (i: I), — если не установлено иное.

Идентификатор: urn:ietf:clir:http-framing#MustLevelFailureDefeatsUnconditionalCompliance Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2

ProcessingConflictingContentLengthDeviates7230

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «multiple_conflicting_content_length» (m: H) и установлено, что «received_by» (m: H, i: I) и установлено, что «processed_as_valid» (i: I, m: H), то «behaviour_deviates» (I, «REJECT_CONFLICTING_CL_7230»).

Идентификатор: urn:ietf:clir:http-framing#ProcessingConflictingContentLengthDeviates7230 Анкер: urn:ietf:clir:http-framing#RFC7230_S3_3_3

RejectingConflictingContentLengthConforms7230

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «multiple_conflicting_content_length» (m: H) и установлено, что «received_by» (m: H, i: I) и установлено, что «responded_bad_request» (i: I, m: H), то «behaviour_conforms» (I, «REJECT_CONFLICTING_CL_7230»).

Идентификатор: urn:ietf:clir:http-framing#RejectingConflictingContentLengthConforms7230 Анкер: urn:ietf:clir:http-framing#RFC7230_S3_3_3

RespondingWithLengthErrorConforms2616

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «received_by» (m: H, i: I) и установлено, что «request_with_body_without_content_length» (m: H) и установлено, что «responded_400_or_411» (i: I, m: H), то «behaviour_conforms» (I, «RESPOND_400_OR_411_2616»).

Идентификатор: urn:ietf:clir:http-framing#RespondingWithLengthErrorConforms2616 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

ShouldLevelFailureDefeatsUnconditionalCompliance

Для Implementation I (v0); Requirement R (v1).

По общему правилу, если установлено, что «behaviour_deviates» (I, R) и установлено, что «recommended_item» (R) и установлено, что «subject_to» (I, R) и установлено, что «claims_conformance» (I, «RFC2616_DOCUMENT»), то не имеет места, что «unconditionally_compliant» (i: I), — если не установлено иное.

Идентификатор: urn:ietf:clir:http-framing#ShouldLevelFailureDefeatsUnconditionalCompliance Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2

UnconditionalComplianceIsPresumed

Для Implementation I (v0); Requirement R (v1).

По общему правилу, если установлено, что «absolute_requirement» (R) и установлено, что «subject_to» (I, R) и установлено, что «claims_conformance» (I, «RFC2616_DOCUMENT»), то «unconditionally_compliant» (i: I), — если не установлено иное.

Идентификатор: urn:ietf:clir:http-framing#UnconditionalComplianceIsPresumed Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2

UsingContentLengthDeviates2616

Для Implementation I (v0); HttpMessage H (v1).

Всегда, если установлено, что «received_by» (m: H, i: I) и установлено, что «used_content_length» (i: I, m: H) и установлено, что «carries_both_framing_fields» (m: H), то «behaviour_deviates» (I, «CL_IGNORED_ON_RECEIPT_2616»).

Идентификатор: urn:ietf:clir:http-framing#UsingContentLengthDeviates2616 Анкер: urn:ietf:clir:http-framing#RFC2616_S4_4

Приоритеты

MustFailureBeatsThePresumptionOfCompliance

При расхождении приоритет имеет правило «MustLevelFailureDefeatsCompliance» перед правилом «ComplianceIsPresumed».

Идентификатор: urn:ietf:clir:http-framing#MustFailureBeatsThePresumptionOfCompliance Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2

MustFailureBeatsUnconditionalCompliance

При расхождении приоритет имеет правило «MustLevelFailureDefeatsUnconditionalCompliance» перед правилом «UnconditionalComplianceIsPresumed».

Идентификатор: urn:ietf:clir:http-framing#MustFailureBeatsUnconditionalCompliance Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2

ShouldFailureBeatsUnconditionalCompliance

При расхождении приоритет имеет правило «ShouldLevelFailureDefeatsUnconditionalCompliance» перед правилом «UnconditionalComplianceIsPresumed».

Идентификатор: urn:ietf:clir:http-framing#ShouldFailureBeatsUnconditionalCompliance Анкер: urn:ietf:clir:http-framing#RFC2616_S1_2