Plan-execute on Where ten HTTP header fields are defined

All ten fields are checked against the pages I opened. The RFC 6797 and RFC 8288 pages I opened show no "Obsoleted by" note, and the RFC 9111 page's header says it obsoletes RFC 7234. I did not open a page confirming that RFC 9110 obsoletes RFC 2616 or RFC 7231, but a search result snippet for it was headed "Specifications Obsoleted by This Document". I did not open the RFC 9110 header itself.

• Age, Cache-Control and Expires: https://www.rfc-editor.org/rfc/rfc9111.html defines these in Sections 5.1, 5.2 and 5.3.
• Last-Modified, ETag, Location, Retry-After and Vary: https://www.rfc-editor.org/rfc/rfc9110.html defines these in Sections 8.8.2, 8.8.3, 10.2.2, 10.2.3 and 12.5.5.
• Strict-Transport-Security: https://www.rfc-editor.org/rfc/rfc6797.html defines it in Section 6.1.
• Link: https://www.rfc-editor.org/rfc/rfc8288.html defines it in Section 3.

One difference from the plan: I did not run separate obsolescence searches for RFC 8288 and RFC 9111. I read each page's header or searched it for "Obsoleted by" instead. The one search I did run, for RFC 6797, turned up no successor.

{"answers":[{"field":"Age","rfc":"9111","section":"5.1","quote":"The Age field value is a non-negative integer, representing time in seconds (see Section 1.2.2).","url":"https://www.rfc-editor.org/rfc/rfc9111.html"},{"field":"Cache-Control","rfc":"9111","section":"5.2","quote":"The \"Cache-Control\" header field is used to list directives for caches along the request/response chain.","url":"https://www.rfc-editor.org/rfc/rfc9111.html"},{"field":"Expires","rfc":"9111","section":"5.3","quote":"The \"Expires\" response header field gives the date/time after which the response is considered stale.","url":"https://www.rfc-editor.org/rfc/rfc9111.html"},{"field":"Last-Modified","rfc":"9110","section":"8.8.2","quote":"An origin server SHOULD send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined, since its use in conditional requests and evaluating cache freshness ([CACHING]) can substantially reduce unnecessary transfers and significantly improve service availability and scalability.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},{"field":"ETag","rfc":"9110","section":"8.8.3","quote":"An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},{"field":"Location","rfc":"9110","section":"10.2.2","quote":"The field value consists of a single URI-reference.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},{"field":"Retry-After","rfc":"9110","section":"10.2.3","quote":"The Retry-After field value can be either an HTTP-date or a number of seconds to delay after receiving the response.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},{"field":"Vary","rfc":"9110","section":"12.5.5","quote":"A proxy MUST NOT generate \"*\" in a Vary field value.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},{"field":"Strict-Transport-Security","rfc":"6797","section":"6.1","quote":"All directives MUST appear only once in an STS header field.","url":"https://www.rfc-editor.org/rfc/rfc6797.html"},{"field":"Link","rfc":"8288","section":"3","quote":"The Link header field provides a means for serialising one or more links into HTTP headers.","url":"https://www.rfc-editor.org/rfc/rfc8288.html"}]}

Two quote choices to flag:

• Last-Modified: the quote comes from Section 8.8.2.1 (Generation), a subsection of 8.8.2. I used it because it is a full sentence from the definition.
• Strict-Transport-Security: the quote is requirement 2 of the numbered list in Section 6.1. The numbering comes from the page's line breaks, so check that quote's wording if you need to be certain.