Plan-execute-verify on Where ten HTTP header fields are defined

All ten fields are defined in five current RFCs. I read each definition on the RFC's own page, and each quote below is copied from that page.

I couldn't check obsolescence directly, because the rfc-editor.org /info/ pages (RFC 6797, 8288, 9111 and 9110) all returned 404. Instead I relied on the RFC texts and a search. RFC 9111 says it obsoletes RFC 7234. RFC 8288 says it obsoletes RFC 5988. RFC 9110's table also lists the older RFCs it replaces. The search turned up no later RFC that replaces 9110, 9111, 6797 or 8288. This is weaker evidence than the "Obsoleted by" line on the info pages, so a newer replacement is unlikely but not ruled out. I found no sources that disagree with each other.

• Age, Cache-Control, Expires are in RFC 9111, sections 5.1, 5.2 and 5.3: https://www.rfc-editor.org/rfc/rfc9111.html
• Last-Modified, ETag, Location, Retry-After, Vary are in RFC 9110, sections 8.8.2, 8.8.3, 10.2.2, 10.2.3 and 12.5.5: https://www.rfc-editor.org/rfc/rfc9110.html
• Strict-Transport-Security is in RFC 6797, section 6.1: https://www.rfc-editor.org/rfc/rfc6797.html
• Link is in RFC 8288, section 3, "Link Serialisation in HTTP Headers": https://www.rfc-editor.org/rfc/rfc8288.html

The plan said to check these RFCs' status on the /info/ pages, but those pages weren't available, so I used the approach above instead. The expected section numbers all matched the headings on the pages.

{"answers":[
{"field":"Age","rfc":"9111","section":"5.1","quote":"The \"Age\" response header field conveys the sender's estimate of the time since the response was generated or successfully validated at the origin server.","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":"The \"Last-Modified\" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},
{"field":"ETag","rfc":"9110","section":"8.8.3","quote":"The \"ETag\" field in a response provides the current entity tag for the selected representation, as determined at the conclusion of handling the request.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},
{"field":"Location","rfc":"9110","section":"10.2.2","quote":"The \"Location\" header field is used in some responses to refer to a specific resource in relation to the response.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},
{"field":"Retry-After","rfc":"9110","section":"10.2.3","quote":"Servers send the \"Retry-After\" header field to indicate how long the user agent ought to wait before making a follow-up request.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},
{"field":"Vary","rfc":"9110","section":"12.5.5","quote":"The \"Vary\" header field in a response describes what parts of a request message, aside from the method and target URI, might have influenced the origin server's process for selecting the content of this response.","url":"https://www.rfc-editor.org/rfc/rfc9110.html"},
{"field":"Strict-Transport-Security","rfc":"6797","section":"6.1","quote":"The Strict-Transport-Security HTTP response header field (STS header field) indicates to a UA that it MUST enforce the HSTS Policy in regards to the host emitting the response message containing this 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"}
]}