Gated-execute on Where ten HTTP header fields are defined

All ten fields are defined in RFCs that are still current. I opened each RFC page on rfc-editor.org and copied the quotes from the section that defines the field. The RFC 6797, 8288, 9110 and 9111 pages I read show no "Obsoleted by" notice. I also ran one search for later RFCs that might replace 6797 or 8288, and it turned up none.

• Age, Cache-Control, Expires: RFC 9111 (HTTP Caching) defines them in sections 5.1, 5.2 and 5.3. https://www.rfc-editor.org/rfc/rfc9111.html
• Last-Modified, ETag, Location, Retry-After, Vary: RFC 9110 (HTTP Semantics) defines them in 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: RFC 6797 defines it in section 6.1. https://www.rfc-editor.org/rfc/rfc6797.html
• Link: RFC 8288 defines it in section 3. https://www.rfc-editor.org/rfc/rfc8288.html

The pages wrap lines in the middle of sentences, so I joined each quote into single-spaced text. I chose quotes that stay inside the field's own section, and I escaped the double quotes in the Last-Modified quote.

{"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":"Cache directives are unidirectional, in that the presence of a directive in a request does not imply that the same directive is present or copied in the response.","url":"https://www.rfc-editor.org/rfc/rfc9111.html"},
{"field":"Expires","rfc":"9111","section":"5.3","quote":"The presence of an Expires header field does not imply that the original resource will change or cease to exist at, before, or after that time.","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":"An entity tag can be either a weak or strong validator, with strong being the default.","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":"Potential selecting header fields are not limited to fields defined by this specification.","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"}
]}