Orchestrator-workers on Where ten HTTP header fields are defined

I found a defining RFC and section for all ten fields. The one gap is that no worker could open the rfc-editor.org status pages, which returned 404. So "not obsoleted" rests on each RFC's own header, which shows no "Obsoleted by" line, and on a search for RFC 9111 that found nothing obsoleting it. The workers saw no disagreement between sources about which RFC is current. I did not open the pages myself and am relying on the workers' reports.

• Age, Cache-Control, Expires: RFC 9111 (HTTP Caching) sections 5.1, 5.2 and 5.3, at https://www.rfc-editor.org/rfc/rfc9111.html. It obsoletes RFC 7234. For Cache-Control, the quote comes from the section 5.2 introduction. The directives themselves are in 5.2.1 and 5.2.2.
• Vary: RFC 9110 (HTTP Semantics) section 12.5.5, at https://www.rfc-editor.org/rfc/rfc9110.html. RFC 9111 section 4.1 only covers how caches use Vary.
• Last-Modified, ETag, Location, Retry-After: RFC 9110 sections 8.8.2, 8.8.3, 10.2.2 and 10.2.3, at https://www.rfc-editor.org/rfc/rfc9110.html. RFC 9110 obsoletes RFCs 7230, 7231, 7232, 7233, 7235 and others.
• Strict-Transport-Security: RFC 6797 section 6.1, at https://www.rfc-editor.org/rfc/rfc6797.html.
• Link: RFC 8288 section 3, at https://www.rfc-editor.org/rfc/rfc8288.html. Its header says it obsoletes RFC 5988. The worker could not open RFC 5988 to check that directly. The IANA registration in section 4.1 is not the definition.

{"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":"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":"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"}]}