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

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

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

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

Источники

RFC9110

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

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

RFC9110_EN

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

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

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

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

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

RFC9110_EN_TEXT

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

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

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

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

RFC9110_S15_3_5

Фрагмент section/15_3_5 издания «RFC9110_EN».

15.3.5. 204 No Content

The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response content. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.

For example, if a 204 status code is received in response to a PUT request and the response contains an ETag field, then the PUT was successful and the ETag field value contains the entity tag for the new representation of that target resource.

The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.

For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.

A 204 response is terminated by the end of the header section; it cannot contain content or trailers.

A 204 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

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

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

RFC9110_S15_5_2

Фрагмент section/15_5_2 издания «RFC9110_EN».

15.5.2. 401 Unauthorized

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 11.6.1) containing at least one challenge applicable to the target resource.

If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 11.6.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.

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

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

RFC9110_S15_5_6

Фрагмент section/15_5_6 издания «RFC9110_EN».

15.5.6. 405 Method Not Allowed

The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.

A 405 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

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

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

RFC9110_S2_2

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

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

This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, or caches, depending on what behavior is being constrained by the requirement. Additional requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication.

The verb "generate" is used instead of "send" where a requirement applies only to implementations that create the protocol element, rather than an implementation that forwards a received element downstream.

An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes in HTTP.

A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules. Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message).

Conformance to HTTP includes both conformance to the particular messaging syntax of the protocol version in use and conformance to the semantics of protocol elements sent. For example, a client that claims conformance to HTTP/1.1 but fails to recognize the features required of HTTP/1.1 recipients will fail to interoperate with servers that adjust their responses in accordance with those claims. Features that reflect user choices, such as content negotiation and user-selected extensions, can impact application behavior beyond the protocol stream; sending protocol elements that inaccurately reflect a user's choices will confuse the user and inhibit choice.

When an implementation fails semantic conformance, recipients of that implementation's messages will eventually develop workarounds to adjust their behavior accordingly. A recipient MAY employ such workarounds while remaining conformant to this protocol if the workarounds are limited to the implementations at fault. For example, servers often scan portions of the User-Agent field value, and user agents often scan the Server field value, to adjust their own behavior with respect to known bugs or poorly chosen defaults.

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

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

RFC9110_S5_3

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

5.3. Field Order

A recipient MAY combine multiple field lines within a field section that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma (",") and optional whitespace (OWS, defined in Section 5.6.3). For consistency, use comma SP.

The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message.

This means that, aside from the well-known exception noted below, a sender MUST NOT generate multiple field lines with the same name in a message (whether in the headers or trailers) or append a field line when a field line of the same name already exists in the message, unless that field's definition allows multiple field line values to be recombined as a comma-separated list (i.e., at least one alternative of the field's definition allows a comma-separated list, such as an ABNF rule of #(values) defined in Section 5.6.1).
  |  *Note:* In practice, the "Set-Cookie" header field ([COOKIE])
  |  often appears in a response message across multiple field lines
  |  and does not use the list syntax, violating the above
  |  requirements on multiple field lines with the same field name.
  |  Since it cannot be combined into a single field value,
  |  recipients ought to handle "Set-Cookie" as a special case while
  |  processing fields.  (See Appendix A.2.3 of [Kri2001] for
  |  details.)
The order in which field lines with differing field names are received in a section is not significant. However, it is good practice to send header fields that contain additional control data first, such as Host on requests and Date on responses, so that implementations can decide when not to handle a message as early as possible.

A server MUST NOT apply a request to the target resource until it receives the entire request header section, since later header field lines might include conditionals, authentication credentials, or deliberately misleading duplicate header fields that could impact request processing.

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

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

RFC9110_S7_2

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

7.2. Host and :authority

The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names.

In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in some cases, supplanted by the ":authority" pseudo-header field of a request's control data.
 Host = uri-host [ ":" port ] ; Section 4
The target URI's authority information is critical for handling a request. A user agent MUST generate a Host header field in a request unless it sends that information as an ":authority" pseudo-header field. A user agent that sends Host SHOULD send it as the first field in the header section of a request.

For example, a GET request to the origin server for http://www.example.org/pub/WWW/ would begin with:

GET /pub/WWW/ HTTP/1.1 Host: www.example.org

Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.

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

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

Понятия

FieldName

Понятие «FieldName».

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

HttpMessage

Понятие «HttpMessage».

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

HttpRole

Понятие «HttpRole».

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

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

ALLOW_IN_405

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

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

AllowField

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

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

HOST_FIRST_FIELD

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

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

HOST_IN_REQUEST

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

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

HostField

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

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

NO_APPLY_BEFORE_HEADER_SECTION

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

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

NO_CONTENT_IN_204

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

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

NO_DUPLICATE_FIELD_LINES

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

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

NO_REORDER_BY_PROXY

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

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

OriginServer

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

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

PRESENT_REPRESENTATION

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

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

Proxy

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

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

REPEAT_WITH_AUTHORIZATION

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

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

RFC9110_DOCUMENT

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

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

Sender

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

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

Server

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

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

UserAgent

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

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

WWW_AUTHENTICATE_IN_401

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

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

WwwAuthenticateField

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

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

acts_as

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

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

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

already_attempted_authentication

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

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

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

applied_before_header_section_complete

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

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

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

carries_content

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

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

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

carries_trailers

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

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

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

duplicate_field_lines

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

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

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

field_allows_comma_list

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

Аргументы: f: FieldName.

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

field_forbids_comma_list

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

Аргументы: f: FieldName.

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

generated_by

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

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

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

has_field

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

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

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

host_not_sent_first

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

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

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

host_sent_first

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

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

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

ill_formed_message

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

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

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

is_request

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

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

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

lacks_field

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

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

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

omits_authority_pseudo_header

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

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

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

presented_representation_to_user

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

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

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

preserved_field_values_order

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

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

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

reordered_field_values

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

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

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

repeated_with_authorization

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

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

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

same_challenge_as_prior

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

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

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

sends_authority_pseudo_header

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

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

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

status_code

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

Аргументы: m: HttpMessage, code: целое число.

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

withheld_representation_from_user

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

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

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

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

assert-1

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

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

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

assert-10

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

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

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

assert-11

Факт: «stated_in» («ALLOW_IN_405», «RFC9110_DOCUMENT»).

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

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

assert-12

Факт: «stated_in» («WWW_AUTHENTICATE_IN_401», «RFC9110_DOCUMENT»).

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

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

assert-13

Факт: «stated_in» («REPEAT_WITH_AUTHORIZATION», «RFC9110_DOCUMENT»).

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

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

assert-14

Факт: «stated_in» («PRESENT_REPRESENTATION», «RFC9110_DOCUMENT»).

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

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

assert-15

Факт: «stated_in» («NO_DUPLICATE_FIELD_LINES», «RFC9110_DOCUMENT»).

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

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

assert-16

Факт: «stated_in» («NO_REORDER_BY_PROXY», «RFC9110_DOCUMENT»).

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

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

assert-17

Факт: «stated_in» («NO_APPLY_BEFORE_HEADER_SECTION», «RFC9110_DOCUMENT»).

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

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

assert-18

Факт: «stated_in» («HOST_IN_REQUEST», «RFC9110_DOCUMENT»).

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

Идентификатор: urn:ietf:clir:http-semantics#assert-18 Анкер: urn:ietf:clir:http-semantics#RFC9110_S7_2

assert-19

Факт: «stated_in» («HOST_FIRST_FIELD», «RFC9110_DOCUMENT»).

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

Идентификатор: urn:ietf:clir:http-semantics#assert-19 Анкер: urn:ietf:clir:http-semantics#RFC9110_S7_2

assert-2

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

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

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

assert-20

Факт: «stated_in» («NO_CONTENT_IN_204», «RFC9110_DOCUMENT»).

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

Идентификатор: urn:ietf:clir:http-semantics#assert-20 Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_3_5

assert-3

Факт: «keyword_written» («REPEAT_WITH_AUTHORIZATION», «May», «AllCapitals»).

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

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

assert-4

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

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

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

assert-5

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

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

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

assert-6

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

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

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

assert-7

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

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

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

assert-8

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

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

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

assert-9

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

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

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

Правила

ApplyingBeforeHeaderSectionDeviates

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

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

Идентификатор: urn:ietf:clir:http-semantics#ApplyingBeforeHeaderSectionDeviates Анкер: urn:ietf:clir:http-semantics#RFC9110_S5_3

ContentIn204IsIllFormed

Для HttpMessage H (v0).

Всегда, если установлено, что «carries_content» (m: H) и установлено, что «status_code» (m: H, code: «204»), то «ill_formed_message» (m: H).

Идентификатор: urn:ietf:clir:http-semantics#ContentIn204IsIllFormed Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_3_5

DuplicateFieldLinesDeviate

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

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

Идентификатор: urn:ietf:clir:http-semantics#DuplicateFieldLinesDeviate Анкер: urn:ietf:clir:http-semantics#RFC9110_S5_3

DuplicateLinesOfAListFieldConform

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

Всегда, если установлено, что «acts_as» (i: I, played: «Sender») и установлено, что «duplicate_field_lines» (m: H, f: F) и установлено, что «field_allows_comma_list» (f: F) и установлено, что «generated_by» (m: H, i: I), то «behaviour_conforms» (I, «NO_DUPLICATE_FIELD_LINES»).

Идентификатор: urn:ietf:clir:http-semantics#DuplicateLinesOfAListFieldConform Анкер: urn:ietf:clir:http-semantics#RFC9110_S5_3

HostNotSentFirstDeviates

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

Всегда, если установлено, что «has_field» (m: H, f: «HostField») и установлено, что «acts_as» (i: I, played: «UserAgent») и установлено, что «generated_by» (m: H, i: I) и установлено, что «host_not_sent_first» (m: H), то «behaviour_deviates» (I, «HOST_FIRST_FIELD»).

Идентификатор: urn:ietf:clir:http-semantics#HostNotSentFirstDeviates Анкер: urn:ietf:clir:http-semantics#RFC9110_S7_2

HostSentFirstConforms

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

Всегда, если установлено, что «has_field» (m: H, f: «HostField») и установлено, что «acts_as» (i: I, played: «UserAgent») и установлено, что «host_sent_first» (m: H) и установлено, что «generated_by» (m: H, i: I), то «behaviour_conforms» (I, «HOST_FIRST_FIELD»).

Идентификатор: urn:ietf:clir:http-semantics#HostSentFirstConforms Анкер: urn:ietf:clir:http-semantics#RFC9110_S7_2

PresentingRepresentationConforms

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

Всегда, если установлено, что «presented_representation_to_user» (i: I, m: H) и установлено, что «already_attempted_authentication» (i: I) и установлено, что «status_code» (m: H, code: «401») и установлено, что «acts_as» (i: I, played: «UserAgent») и установлено, что «same_challenge_as_prior» (m: H), то «behaviour_conforms» (I, «PRESENT_REPRESENTATION»).

Идентификатор: urn:ietf:clir:http-semantics#PresentingRepresentationConforms Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_5_2

PreservingOrderConforms

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

Всегда, если установлено, что «preserved_field_values_order» (i: I, m: H) и установлено, что «acts_as» (i: I, played: «Proxy»), то «behaviour_conforms» (I, «NO_REORDER_BY_PROXY»).

Идентификатор: urn:ietf:clir:http-semantics#PreservingOrderConforms Анкер: urn:ietf:clir:http-semantics#RFC9110_S5_3

ReorderingByProxyDeviates

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

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

Идентификатор: urn:ietf:clir:http-semantics#ReorderingByProxyDeviates Анкер: urn:ietf:clir:http-semantics#RFC9110_S5_3

RepeatingRequestExercisesTheOption

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

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

Идентификатор: urn:ietf:clir:http-semantics#RepeatingRequestExercisesTheOption Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_5_2

RequestWithAuthorityPseudoHeaderConforms

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

Всегда, если установлено, что «acts_as» (i: I, played: «UserAgent») и установлено, что «sends_authority_pseudo_header» (m: H) и установлено, что «generated_by» (m: H, i: I) и установлено, что «is_request» (m: H), то «behaviour_conforms» (I, «HOST_IN_REQUEST»).

Идентификатор: urn:ietf:clir:http-semantics#RequestWithAuthorityPseudoHeaderConforms Анкер: urn:ietf:clir:http-semantics#RFC9110_S7_2

RequestWithHostConforms

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

Всегда, если установлено, что «has_field» (m: H, f: «HostField») и установлено, что «acts_as» (i: I, played: «UserAgent») и установлено, что «generated_by» (m: H, i: I) и установлено, что «is_request» (m: H), то «behaviour_conforms» (I, «HOST_IN_REQUEST»).

Идентификатор: urn:ietf:clir:http-semantics#RequestWithHostConforms Анкер: urn:ietf:clir:http-semantics#RFC9110_S7_2

RequestWithoutHostDeviates

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

Всегда, если установлено, что «omits_authority_pseudo_header» (m: H) и установлено, что «lacks_field» (m: H, f: «HostField») и установлено, что «acts_as» (i: I, played: «UserAgent») и установлено, что «generated_by» (m: H, i: I) и установлено, что «is_request» (m: H), то «behaviour_deviates» (I, «HOST_IN_REQUEST»).

Идентификатор: urn:ietf:clir:http-semantics#RequestWithoutHostDeviates Анкер: urn:ietf:clir:http-semantics#RFC9110_S7_2

Status401WithChallengeConforms

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

Всегда, если установлено, что «status_code» (m: H, code: «401») и установлено, что «has_field» (m: H, f: «WwwAuthenticateField») и установлено, что «acts_as» (i: I, played: «Server») и установлено, что «generated_by» (m: H, i: I), то «behaviour_conforms» (I, «WWW_AUTHENTICATE_IN_401»).

Идентификатор: urn:ietf:clir:http-semantics#Status401WithChallengeConforms Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_5_2

Status401WithoutChallengeDeviates

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

Всегда, если установлено, что «status_code» (m: H, code: «401») и установлено, что «lacks_field» (m: H, f: «WwwAuthenticateField») и установлено, что «acts_as» (i: I, played: «Server») и установлено, что «generated_by» (m: H, i: I), то «behaviour_deviates» (I, «WWW_AUTHENTICATE_IN_401»).

Идентификатор: urn:ietf:clir:http-semantics#Status401WithoutChallengeDeviates Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_5_2

Status405WithAllowConforms

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

Всегда, если установлено, что «status_code» (m: H, code: «405») и установлено, что «acts_as» (i: I, played: «OriginServer») и установлено, что «has_field» (m: H, f: «AllowField») и установлено, что «generated_by» (m: H, i: I), то «behaviour_conforms» (I, «ALLOW_IN_405»).

Идентификатор: urn:ietf:clir:http-semantics#Status405WithAllowConforms Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_5_6

Status405WithoutAllowDeviates

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

Всегда, если установлено, что «status_code» (m: H, code: «405») и установлено, что «acts_as» (i: I, played: «OriginServer») и установлено, что «lacks_field» (m: H, f: «AllowField») и установлено, что «generated_by» (m: H, i: I), то «behaviour_deviates» (I, «ALLOW_IN_405»).

Идентификатор: urn:ietf:clir:http-semantics#Status405WithoutAllowDeviates Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_5_6

TrailersIn204AreIllFormed

Для HttpMessage H (v0).

Всегда, если установлено, что «status_code» (m: H, code: «204») и установлено, что «carries_trailers» (m: H), то «ill_formed_message» (m: H).

Идентификатор: urn:ietf:clir:http-semantics#TrailersIn204AreIllFormed Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_3_5

WithholdingRepresentationDeviates

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

Всегда, если установлено, что «already_attempted_authentication» (i: I) и установлено, что «status_code» (m: H, code: «401») и установлено, что «acts_as» (i: I, played: «UserAgent») и установлено, что «withheld_representation_from_user» (i: I, m: H) и установлено, что «same_challenge_as_prior» (m: H), то «behaviour_deviates» (I, «PRESENT_REPRESENTATION»).

Идентификатор: urn:ietf:clir:http-semantics#WithholdingRepresentationDeviates Анкер: urn:ietf:clir:http-semantics#RFC9110_S15_5_2