Опубликованный пакет / CLIR
ietf.http_framing
v0.1.0Hypertext Transfer Protocol -- HTTP/1.1
Пломба §208
sha256:a2cd69e3b97ad54e37c7f4f5b672611db745107b7f76c2e359fe2f6f319d2042Подключить /
law.toml[dependencies] ietf.http_framing = "0.1.0"
Получить канонические байты
curl -O /blobs/a2cd69e3b97ad54e37c7f4f5b672611db745107b7f76c2e359fe2f6f319d2042.lawir.json
Все адресуемые узлы пакета. Помеченные internal — не часть контракта: сослаться на них из другого пакета нельзя (§24). Свою страницу имеют только публичные символы.
symbol_decl — 33
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| CL_IGNORED_ON_RECEIPT_2616 | if a message is received with both a Transfer-Encoding and a Content-Length header field, the latter MUST be ignored (RFC 2616, Section 4.4) | internal | |
| CL_NOT_SENT_WITH_TE_2616 | the Content-Length header field MUST NOT be sent if a Transfer-Encoding header field is present (RFC 2616, Section 4.4) | internal | |
| Intermediary | an intermediary | internal | |
| MESSAGE_MUST_NOT_INCLUDE_BOTH_2616 | messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding (RFC 2616, Section 4.4) | internal | |
| REJECT_CONFLICTING_CL_7230 | if a message is received with multiple Content-Length fields having differing values, the recipient MUST treat it as an unrecoverable error (RFC 7230, Section 3.3.3) | internal | |
| REMOVE_CL_AND_PROCESS_TE_9112 | an intermediary that chooses to forward the message MUST first remove the received Content-Length field and process the Transfer-Encoding prior to forwarding (RFC 9112, Section 6.3) | internal | |
| REMOVE_CL_BEFORE_FORWARDING_7230 | a sender MUST remove the received Content-Length field prior to forwarding such a message downstream (RFC 7230, Section 3.3.3) | internal | |
| RESPOND_400_OR_411_2616 | the server SHOULD respond with 400 (bad request) or 411 (length required) when it cannot determine the message length (RFC 2616, Section 4.4) | internal | |
| RFC2616_DOCUMENT | RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 (1999) | internal | |
| RFC7230_DOCUMENT | RFC 7230, HTTP/1.1 Message Syntax and Routing (2014) | internal | |
| RFC9112_DOCUMENT | RFC 9112, HTTP/1.1 (2022) | internal | |
| Recipient | a recipient | internal | |
| Sender | a sender | internal | |
| accepted_without_length | the server accepted the request although it could not determine the message length | internal | |
| acts_as | the participant acts in this role for the exchange | internal | |
| carries_both_framing_fields | the message carries both a Transfer-Encoding and a Content-Length header field | internal | |
| compliant | the implementation is compliant with RFC 2616 in the sense of its Section 1.2 | internal | |
| conditionally_compliant | the implementation is conditionally compliant: it satisfies the MUST level requirements but not all the SHOULD level requirements | internal | |
| forwarded_downstream | the participant forwarded the message downstream | internal | |
| generated_by | the message was generated by this participant | internal | |
| has_content_length | the message carries a Content-Length header field | internal | |
| has_transfer_encoding | the message carries a Transfer-Encoding header field | internal | |
| ignored_content_length | the recipient ignored the Content-Length field when determining the message length | internal | |
| kept_content_length_when_forwarding | the participant forwarded the message with the received Content-Length field intact | internal | |
| multiple_conflicting_content_length | the message carries multiple Content-Length header fields with differing field-values | internal | |
| processed_as_valid | the recipient processed the message as a valid one | internal | |
| received_by | the message was received by this participant | internal | |
| removed_content_length_before_forwarding | the participant removed the received Content-Length field before forwarding | internal | |
| request_with_body_without_content_length | the request contains a message-body and no Content-Length is given | internal | |
| responded_400_or_411 | the server responded with 400 (bad request) or 411 (length required) | internal | |
| responded_bad_request | the server responded with 400 (Bad Request) and closed the connection | internal | |
| unconditionally_compliant | the implementation is unconditionally compliant: it satisfies the MUST level and the SHOULD level requirements | internal | |
| used_content_length | the recipient used the Content-Length field when determining the message length | internal |
type_decl — 2
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| FramingRole | the role in which a participant is addressed by a framing requirement | internal | |
| HttpMessage | an HTTP/1.1 message | internal |
rule — 19
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| AcceptingBodyWithoutLengthDeviates2616 | if a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 or 411 | 1 | internal |
| BothFramingFieldsPresent | a message with both a Transfer-Encoding and a Content-Length header field | internal | |
| ComplianceIsPresumed | an implementation subject to a MUST or REQUIRED level requirement is taken to be compliant until a failure is shown | 1 | internal |
| ConditionalComplianceIsTheMiddleTerm | one that satisfies all the MUST level requirements but not all the SHOULD level requirements is said to be conditionally compliant | 1 | internal |
| ForwardingWithContentLengthDeviates7230 | a sender MUST remove the received Content-Length field prior to forwarding such a message downstream | 1 | internal |
| ForwardingWithoutContentLengthConforms7230 | removing the received Content-Length field before forwarding conforms to Section 3.3.3 | 1 | internal |
| GeneratingBothFieldsDeviates2616 | the Content-Length header field MUST NOT be sent if a Transfer-Encoding header field is present | 1 | internal |
| IgnoringContentLengthConforms2616 | if a message is received with both fields, the latter MUST be ignored | 1 | internal |
| IncludingBothFieldsDeviates2616 | messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding | 1 | internal |
| IntermediaryForwardingWithContentLengthDeviates9112 | an intermediary that chooses to forward the message MUST first remove the received Content-Length field prior to forwarding the message downstream | 1 | internal |
| IntermediaryRemovingContentLengthConforms9112 | removing the received Content-Length field before forwarding conforms to Section 6.3 | 1 | internal |
| MustLevelFailureDefeatsCompliance | an implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements | 1 | internal |
| MustLevelFailureDefeatsUnconditionalCompliance | a MUST level failure defeats unconditional compliance | 1 | internal |
| ProcessingConflictingContentLengthDeviates7230 | if a message is received with multiple Content-Length fields having differing values, the recipient MUST treat it as an unrecoverable error | 1 | internal |
| RejectingConflictingContentLengthConforms7230 | responding with 400 (Bad Request) and closing the connection conforms to Section 3.3.3 | 1 | internal |
| RespondingWithLengthErrorConforms2616 | responding with 400 (bad request) or 411 (length required) conforms to the recommendation of Section 4.4 | 1 | internal |
| ShouldLevelFailureDefeatsUnconditionalCompliance | a SHOULD level failure defeats unconditional compliance while leaving compliance intact | 1 | internal |
| UnconditionalComplianceIsPresumed | an implementation subject to a MUST or REQUIRED level requirement is taken to be unconditionally compliant until a failure is shown | 1 | internal |
| UsingContentLengthDeviates2616 | using the Content-Length of a message that also carries Transfer-Encoding deviates from Section 4.4 | 1 | internal |
priority_rule — 3
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| MustFailureBeatsThePresumptionOfCompliance | a shown MUST level failure prevails over the presumption of compliance | 1 | internal |
| MustFailureBeatsUnconditionalCompliance | a shown MUST level failure prevails over the presumption of unconditional compliance | 1 | internal |
| ShouldFailureBeatsUnconditionalCompliance | a shown SHOULD level failure prevails over the presumption of unconditional compliance | 1 | internal |
assertion — 17
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| assert-1 | — | 1 | internal |
| assert-10 | — | 1 | internal |
| assert-11 | — | 1 | internal |
| assert-12 | — | 1 | internal |
| assert-13 | — | 1 | internal |
| assert-14 | — | 1 | internal |
| assert-15 | — | 1 | internal |
| assert-16 | — | 1 | internal |
| assert-17 | — | 1 | internal |
| assert-2 | — | 1 | internal |
| assert-3 | — | 1 | internal |
| assert-4 | — | 1 | internal |
| assert-5 | — | 1 | internal |
| assert-6 | — | 1 | internal |
| assert-7 | — | 1 | internal |
| assert-8 | — | 1 | internal |
| assert-9 | — | 1 | internal |
fragment — 6
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| RFC2616_S1_2 | — | internal | |
| RFC2616_S4_4 | — | internal | |
| RFC7230_S1_1 | — | internal | |
| RFC7230_S3_3_3 | — | internal | |
| RFC9112_S1_1 | — | internal | |
| RFC9112_S6_3 | — | internal |
publication — 3
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| RFC2616_EN_TEXT | — | internal | |
| RFC7230_EN_TEXT | — | internal | |
| RFC9112_EN_TEXT | — | internal |
reference — 2
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| RFC7230_OBSOLETES_RFC2616 | Obsoletes: 2616 (RFC 7230, June 2014) | internal | |
| RFC9112_OBSOLETES_RFC7230 | Obsoletes: 7230 (RFC 9112, June 2022) | internal |
source_edition — 3
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| RFC2616_EN | RFC 2616 (R. Fielding et al.) | internal | |
| RFC7230_EN | RFC 7230 (R. Fielding, J. Reschke, eds.) | internal | |
| RFC9112_EN | RFC 9112 (R. Fielding, M. Nottingham, J. Reschke, eds.) | internal |
source_work — 3
| Узел | Подпись | Анкеры §194 | |
|---|---|---|---|
| RFC2616 | Hypertext Transfer Protocol -- HTTP/1.1 | internal | |
| RFC7230 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing | internal | |
| RFC9112 | HTTP/1.1 | internal |