RFC 9112 Quiz

**Explanation:** header section, empty line, CRLF. HTTP/1.1 uses a blank line to separate headers from the optional message body. The header section ends at the empty line, which is a CRLF on its own, after the last header field line. - A (incorrect): Content-Length is about body framing. It does not terminate the header section. - B (incorrect): That CRLF terminates one field line; the grammar requires another CRLF as an empty line to end the section. - C (correct): The CRLF empty line is the defined delimiter. When parsers disagree on where headers end, intermediaries can be vulnerable to request smuggling.

**Explanation:** A close-delimited response is a response whose body ends when the server closes the connection instead of at a declared length or chunked terminator. Under RFC 9112 Section 6.3, an otherwise body-bearing response without a declared body length contains all octets received before the server closes the connection. - A (incorrect): The no-body default applies to a request when no earlier framing rule applies, not to this 200 response. - B (incorrect): CRLF can occur inside body content and is not the delimiter for a close-delimited response. - C (correct): Connection closure supplies the delimiter, so every preceding body octet contributes to the length. A close-delimited response cannot distinguish normal completion from a network interruption, so RFC 9112 recommends explicit length or transfer coding when possible.

**Explanation:** chunked coding, chunk size, terminator. Chunked transfer coding frames the body as a series of chunks. A zero-size last chunk ends the content chunks. An optional trailer section can follow, and a final empty line terminates the chunked coding. - A (incorrect): Connection close is not the normal terminator for chunked coding and should not be relied upon. - B (correct): The zero-size chunk signals that content chunks are complete; any trailer fields and the final empty line complete the coding. - C (incorrect): Content-Length is not used as a trailer to end a chunked body. Trailer fields come after the zero-size last chunk and before the final empty line.

**Explanation:** request-target, origin-form, absolute-form, authority-form, asterisk-form. Different forms are used depending on whether the client is talking to an origin server, proxy, or using CONNECT/OPTIONS. All four forms are defined and used in specific situations. - A (correct): Common for origin servers, like /path?query. - B (correct): Used when making requests to proxies, like http://example.com/path. - C (correct): Used with CONNECT to establish a tunnel to host:port. - D (correct): Used with OPTIONS * to query server-wide options. - E (incorrect): HTTP/1.1 has a Host field, but it does not define a request-target form named host-form. - F (incorrect): A URI scheme can appear within absolute-form; scheme-form is not a separately defined request-target form. Proxies must carefully preserve semantics and not accidentally rewrite request-target incorrectly.

**Explanation:** A: A close-delimited response ends only when the connection ends; no later response can be framed on that closed connection. B: RFC 9112 Section 6.3 defines the body as all octets before server closure. Section 9.3 requires self-defined message lengths for persistence, such as valid Content-Length or final chunked coding where applicable. C: CRLF inside an arbitrary response body is data, not a reliable next-message boundary. D: Persistent connections are the HTTP/1.1 default when framing and connection options permit them. Decision rule: Persistence is not enough by itself; every message on a reusable connection needs a length independent of connection closure.

**Explanation:** A: Different framing decisions across hops are the request-smuggling condition, not acceptable extensibility. B: RFC 9112 Section 6.3 gives Transfer-Encoding precedence. Substituting the conflicting Content-Length can change the message boundary. C: Section 6.3 says the combination might indicate request smuggling and ought to be handled as an error. An intermediary that chooses to forward must remove Content-Length and process Transfer-Encoding first. D: Equality checked after parsing does not make forwarding both fields safe; the downstream might select a boundary before that comparison. Decision rule: Establish one canonical message boundary at the receiving hop before forwarding; never preserve competing length signals across a trust boundary.