RFC 7541 Quiz

**Explanation:** HPACK represents HTTP/2 header fields as indexed references or literals. Its static table is fixed by the specification; its dynamic table is synchronized for a connection. Reusing table entries and compact literal encodings reduces repeated header bytes, which is HPACK's purpose. HPACK can reduce the encoded size of a header block, but it does not encrypt header fields; transport confidentiality is a separate concern. Indexed and literal representations remove redundancy while allowing the decoder to reconstruct the same ordered header list. HPACK does not authenticate the server or replace certificate validation. HTTP/3 uses QPACK, whose table synchronization is adapted to QUIC's stream delivery model.

**Explanation:** The static and dynamic tables share one index address space, but only the dynamic table is updated by encoder instructions. Entries are inserted into and evicted from the dynamic table as header blocks are encoded and decoded. The static table's entries and indices are fixed by RFC 7541 and do not evolve with traffic. A DNS cache is not part of HPACK's encoding or decoding context. Each direction has an independent dynamic table. For a given direction, the encoder's state and the peer decoder's corresponding state must remain synchronized. If their dynamic-table state diverges, indexed references can decode to the wrong field or produce a compression error.

**Explanation:** A literal header field marked **never indexed** is intended for values that should not be inserted into a compression table. RFC 7541 uses credentials and cookies as examples of sensitive fields. These example values carry bearer or session material that can be reused if exposed. A bearer token is a reusable credential, so retaining it in compression state increases exposure. This media-type preference is not a credential or session identifier in the stated example. A session cookie can authorize later requests and should be treated as secret material. A response that sets a session identifier carries the same kind of reusable secret. Sensitivity is a property of the value and threat model. A field name alone is not a universal rule for every deployment.

**Explanation:** In HTTP/2, the decoder advertises a maximum with **SETTINGS_HEADER_TABLE_SIZE**. The encoder can choose a smaller current size but cannot exceed that bound. The acknowledged setting is the protocol-defined maximum for the encoder's dynamic table. It lets the decoder bound persistent compression state and therefore its memory commitment. The static table is a separate fixed table; its entry count does not bound the dynamic table. A header block can span frames, and frame payload size is not the dynamic-table capacity limit. The encoder signals a chosen lower size with a dynamic table size update at the start of a header block.

**Explanation:** B is correct. Section 5.2 permits only padding of at most seven bits that matches the most significant bits of the EOS symbol. Padding longer than seven bits or with the wrong pattern is a decoding error; an encoded EOS symbol is also an error. A would silently normalize malformed wire data and could make implementations interpret the same block differently. C invents a fallback that the format does not define: the H bit determines how the stated bytes are decoded. Appendix B fixes the Huffman code, but it does not relax termination validation.

**Explanation:** A **compression oracle** exists when an attacker can influence part of the input and observe how encoded length changes relative to a secret in the same compression context. Repeated length observations can reveal whether an attacker-controlled guess shares structure with the secret. The side channel leaks information through size behavior; HPACK does not place TLS traffic keys into header blocks. TLS can still authenticate the encrypted record; authenticated transport does not remove information exposed through a length oracle. This is the probing risk described in RFC 7541's security considerations. Never-indexed representations and separating compression contexts reduce some risks, but the design still needs an explicit attacker-influence analysis.

**Explanation:** RFC 7541 Sections 7.1 and 7.1.1 describe this attacker model directly: mutually distrustful entities share a compression context, one can influence encoded fields, and it can observe lengths. TLS protects content but exposes enough length information for dynamic-table probing, especially when a secret has low entropy. Sections 7.1.2 and 7.1.3 describe mitigation choices, with segregation of dynamic-table access by the field-constructing entity as an ideal solution. Cookie and Authorization are examples of sensitive values that an encoder might send as never-indexed literals. Section 6.2.3 requires an intermediary to preserve the never-indexed representation when it re-encodes with HPACK. Never-indexing does not hide the literal's length or solve every side channel. It prevents insertion and reuse through the dynamic table, so the remaining length exposure and any hop that terminates or recreates compression still require threat analysis.

**Explanation:** C is correct. Sections 7.3 and 7.4 distinguish dynamic-table state from temporary processing memory. A decoder can bound table memory with the HTTP/2 setting, but it must also limit accepted integer values, integer encoding lengths, and string literal lengths. Sequential processing can reduce temporary memory, subject to application needs. A confuses one state limit with every allocation made during decoding. B confuses transport framing with HPACK value limits; a header block can span frames, and Section 7.4 still requires implementation bounds. Setting the table to zero is useful, but it is not a complete resource-exhaustion defense.