# checklist-9113-8.3.1

tool: generate_checklist
args: {"rfc":9113,"sections":["8.3.1"]}

--- markdown ---
# RFC 9113 Implementation Checklist

**HTTP/2**

Generated: <generatedAt>

## Mandatory Requirements (MUST / REQUIRED / SHALL)

- [ ] **MUST NOT** The recipient of an HTTP/2 request MUST NOT use the Host header field to determine the target URI if ":authority" is present. (§8.3.1)
- [ ] **MUST** Clients that generate HTTP/2 requests directly MUST use the ":authority" pseudo-header field to convey authority information, unless there is no authority information to convey (in which case it MUST NOT generate ":authority"). (§8.3.1)
- [ ] **MUST NOT** Clients that generate HTTP/2 requests directly MUST use the ":authority" pseudo-header field to convey authority information, unless there is no authority information to convey (in which case it MUST NOT generate ":authority"). (§8.3.1)
- [ ] **MUST NOT** Clients MUST NOT generate a request with a Host header field that differs from the ":authority" pseudo-header field. (§8.3.1)
- [ ] **MUST** An origin server can apply any normalization method, whereas other servers MUST perform scheme-based normalization (see Section 6.2.3 of [RFC3986]) of the two fields. (§8.3.1)
- [ ] **MUST** An intermediary that forwards a request over HTTP/2 MUST construct an ":authority" pseudo-header field using the authority information from the control data of the original request, unless the original request's target URI does not contain authority information (in which case it MUST NOT generate ":authority"). (§8.3.1)
- [ ] **MUST NOT** An intermediary that forwards a request over HTTP/2 MUST construct an ":authority" pseudo-header field using the authority information from the control data of the original request, unless the original request's target URI does not contain authority information (in which case it MUST NOT generate ":authority"). (§8.3.1)
- [ ] **MUST** An intermediary that needs to generate a Host header field (which might be necessary to construct an HTTP/1.1 request) MUST use the value from the ":authority" pseudo-header field as the value of the Host field, unless the intermediary also changes the request target. (§8.3.1)
- [ ] **MUST NOT** ":authority" MUST NOT include the deprecated userinfo subcomponent for "http" or "https" schemed URIs. (§8.3.1)
- [ ] **MUST NOT** This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a value of '/'. (§8.3.1)
- [ ] **MUST** This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a value of '/'. (§8.3.1)
- [ ] **MUST** The exceptions to this rule are: an OPTIONS request for an "http" or "https" URI that does not include a path component; these MUST include a ":path" pseudo-header field with a value of '*' (see Section 7.1 of [HTTP]). (§8.3.1)
- [ ] **MUST** All HTTP/2 requests MUST include exactly one valid value for the ":method", ":scheme", and ":path" pseudo-header fields, unless they are CONNECT requests (Section 8.5). (§8.3.1)

## Recommended Requirements (SHOULD / RECOMMENDED)

- [ ] **SHOULD** A server SHOULD treat a request as malformed if it contains a Host header field that identifies an entity that differs from the entity in the ":authority" pseudo-header field. (§8.3.1)

## Optional Requirements (MAY / OPTIONAL)

- [ ] **MAY** An intermediary that forwards a request over HTTP/2 MAY retain any Host header field. (§8.3.1)

--- json ---
{
  "rfc": 9113,
  "role": "both",
  "stats": {
    "must": 13,
    "should": 1,
    "may": 1,
    "total": 15
  },
  "_source": "xml"
}