Update some to 9111

Author: mnot

index.html

@@ -67,7 +67,7 @@ <h1 class='noFrame'>HTTP Caching Tests</h1>
     contributions, add your implementation's results, file issues or learn more, see <a
     href="https://github.com/http-tests/cache-tests">the repository</a>.</p>
 
-    <p class='noFrame'>See also <a href="/spec/cache.html">test results interspersed with the current specification text</a>.</p>
+    <p class='noFrame'>See also <a href="/spec/rfc9111.html">test results interspersed with the current specification text</a>.</p>
 
     <p id="key">
       <span class="key-item"><span class="fa" data-kind="pass"></span>passed &nbsp;</span>

spec/Makefile

@@ -7,7 +7,7 @@ saxparam ?= bootstrapCssUrl='/spec/bootstrap.min.css' \
 						banner='This copy of the specification has test results interspersed throughout; click on ℹ️ to see them.'
 stylesheet := lib/rfcbootstrap.xslt
 
-specs := cache
+specs := rfc9111
 TARGETS := $(addsuffix .html,$(specs))
 
 .PHONY: all clean

spec/cache.html

@@ -147,7 +147,7 @@
    A <x:dfn>shared cache</x:dfn> is a cache that stores responses for reuse
    by more than one user; shared caches are usually (but not always) deployed
    as a part of an intermediary. A <x:dfn>private cache</x:dfn>, in contrast,
-   is dedicated to a single user; often, they are deployed as a component of 
+   is dedicated to a single user; often, they are deployed as a component of
    a user agent.
 </t>
 <t>
@@ -187,7 +187,7 @@
    <xref target="RFC5234"/>, extended with the notation for case-sensitivity
    in strings defined in <xref target="RFC7405"/>.
 </t>
-<t>   
+<t>
    It also uses a list extension, defined in <xref target="abnf.extension"/>,
    that allows for compact definition of comma-separated lists using a '#'
    operator (similar to how the '*' operator indicates repetition). <xref
@@ -237,7 +237,7 @@
 </t>
 <aside>
    <t>
-       &Note; The value 2147483648 is here for historical reasons, 
+       &Note; The value 2147483648 is here for historical reasons,
        represents infinity (over 68 years), and does not need to be stored in
        binary form; an implementation could produce it as a canned string if
        any overflow occurs, even if the calculations are performed with an
@@ -288,7 +288,7 @@
    Most commonly, caches store the successful result of a retrieval
    request: i.e., a <x:ref>200 (OK)</x:ref> response to a GET request, which
    contains a representation of the target resource
-   (<xref target="GET"/>). However, it is also possible to store 
+   (<xref target="GET"/>). However, it is also possible to store
    redirects, negative results (e.g., <x:ref>404 (Not Found)</x:ref>),
    incomplete results (e.g., <x:ref>206 (Partial Content)</x:ref>), and
    responses to methods other than GET if the method's definition allows such
@@ -344,7 +344,7 @@
   </li>
 </ul>
 <t>
-   Note that a cache-control extension can override any of the requirements 
+   Note that a cache-control extension can override any of the requirements
    listed; see <xref target="cache.control.extensions" />.
 </t>
 <t>
@@ -562,7 +562,7 @@
    need to be forwarded to be satisfied.
 </t>
 <t>
-   When more than one suitable response is stored, a cache &MUST; use the 
+   When more than one suitable response is stored, a cache &MUST; use the
    most recent one (as determined by the <x:ref>Date</x:ref> header
    field). It can also forward the request with "Cache-Control: max-age=0" or
    "Cache-Control: no-cache" to disambiguate which response to use.
@@ -626,16 +626,16 @@
 </t>
 <t>
    Some resources mistakenly omit the Vary header field from their default
-   response (i.e., the one sent when no more preferable response is available), 
-   with the effect of selecting it for requests to that resource even when 
+   response (i.e., the one sent when no more preferable response is available),
+   with the effect of selecting it for requests to that resource even when
    more preferable responses are available. When a cache has multiple responses for a
    target URI and one or more omits the Vary header field, it &SHOULD; use the
    most recent (see <xref target="age.calculations"/>) valid Vary field value available to select an appropriate response
    for the request.
 </t>
 <t>
-   If no selected response is available, the cache cannot satisfy the 
-   presented request. Typically, it is forwarded to the origin server 
+   If no selected response is available, the cache cannot satisfy the
+   presented request. Typically, it is forwarded to the origin server
    in a (possibly conditional; see <xref target="validation.model"/>) request.
 </t>
 </section>
@@ -663,7 +663,7 @@
 <iref item="age" />
 <t>
    A response's <x:dfn>age</x:dfn> is the time that has passed since it was
-   generated by, or successfully validated with, the origin server.  
+   generated by, or successfully validated with, the origin server.
 </t>
 <t>
    When a response is fresh, it can be used to satisfy
@@ -713,7 +713,7 @@
    When calculating freshness, to avoid common problems in date parsing:
 </t>
 <ul>
-   <li>Although all date formats are specified to be case-sensitive, 
+   <li>Although all date formats are specified to be case-sensitive,
       a cache recipient &SHOULD; match the field value
       case-insensitively.</li>
    <li>If a cache recipient's internal implementation of time has less
@@ -870,7 +870,7 @@
   apparent_age = max(0, response_time - date_value);
 
   response_delay = response_time - request_time;
-  corrected_age_value = age_value + response_delay;  
+  corrected_age_value = age_value + response_delay;
 </artwork>
 <t>
    The corrected_age_value &MAY; be used as the corrected_initial_age. In
@@ -1095,7 +1095,7 @@
      recent of those matching stored responses is identified for update.
    </li>
    <li>
-     If the new response does not include any form of validator (such as 
+     If the new response does not include any form of validator (such as
      where a client generates an <x:ref>If-Modified-Since</x:ref> request from
      a source other than the <x:ref>Last-Modified</x:ref> response header
      field), and there is only one stored response, and that stored response
@@ -1243,9 +1243,9 @@
 </t>
 <t>
    A proxy, whether or not it implements a cache, &MUST; pass cache directives
-   through in forwarded messages, regardless of their 
-   significance to that application, since the directives might apply 
-   to all recipients along the request/response chain. It is not possible to 
+   through in forwarded messages, regardless of their
+   significance to that application, since the directives might apply
+   to all recipients along the request/response chain. It is not possible to
    target a directive to a specific cache.
 </t>
 <t>
@@ -1345,7 +1345,7 @@
    validation on the origin server.
 </t>
 </section>
- 
+
 <section title="no-store" anchor="cache-request-directive.no-store">
    <iref item="no-store (cache directive)" primary="true" />
 <t>
@@ -1418,7 +1418,7 @@
    e.g., 'max-age=5' not 'max-age="5"'. A sender &MUST-NOT; generate the
    quoted-string form.
 </t>
-</section>      
+</section>
 
 <section title="must-revalidate" anchor="cache-response-directive.must-revalidate">
    <iref item="must-revalidate (cache directive)" primary="true" />
@@ -1495,7 +1495,7 @@
    This allows an origin server to prevent the re-use of certain header
    fields in a response, while still allowing caching of the rest of the
    response.
-</t> 
+</t>
 <t>
    The field names given are not limited to the set of header
    fields defined by this specification. Field names are case-insensitive.
@@ -1625,7 +1625,7 @@
    is already cacheable according to <xref target="response.cacheability"/>.
 </t>
 <t>
-   If a response with the public directive has no explicit freshness information, 
+   If a response with the public directive has no explicit freshness information,
    it is heuristically cacheable (<xref target="heuristic.freshness"/>).
 </t>
 </section>
@@ -1674,7 +1674,7 @@
    Informational extensions (those that do not require a change in cache
    behavior) can be added without changing the semantics of other directives.
 </t>
-<t>   
+<t>
    Behavioral extensions are designed to work by acting as modifiers to the
    existing base of cache directives.
    Both the new directive and the old directive are supplied, such that
@@ -1781,11 +1781,11 @@
    with a reliable clock.
 </t>
 <t>
-   Historically, HTTP required the Expires field value to be no more than a 
-   year in the future. While longer freshness lifetimes are no longer 
-   prohibited, extremely large values have been demonstrated to cause 
-   problems (e.g., clock overflows due to use of 32-bit integers for 
-   time values), and many caches will evict a response far sooner than 
+   Historically, HTTP required the Expires field value to be no more than a
+   year in the future. While longer freshness lifetimes are no longer
+   prohibited, extremely large values have been demonstrated to cause
+   problems (e.g., clock overflows due to use of 32-bit integers for
+   time values), and many caches will evict a response far sooner than
    that.
 </t>
 </section>
@@ -1910,7 +1910,7 @@
 <t>
    Because one of the primary uses of a cache is to optimise performance,
    its use can "leak" information about what resources have been previously
-   requested. 
+   requested.
 </t>
 <t>
    For example, if a user visits a site and their browser caches some of its
@@ -1953,9 +1953,9 @@
 <section title="Field Name Registration" anchor="field.name.registration">
 <t>
    First, introduce the new "Hypertext Transfer Protocol (HTTP) Field
-   Name Registry" at <eref target="https://www.iana.org/assignments/http-fields"/> 
-   as described in 
-   <xref target="Semantics" x:rel="#field.name.registration"/>. 
+   Name Registry" at <eref target="https://www.iana.org/assignments/http-fields"/>
+   as described in
+   <xref target="Semantics" x:rel="#field.name.registration"/>.
 </t>
 <t>
    Then, please update the registry with the field names listed in the table
@@ -2136,13 +2136,13 @@
 <references title="Normative References">
 
   <reference anchor="Messaging">
-    <x:source basename="draft-ietf-httpbis-messaging-latest" href="draft-ietf-httpbis-messaging-latest.xml">
+    <x:source basename="draft-ietf-httpbis-messaging-latest" href="rfc9110.xml">
       <x:has anchor="message.body.length"/>
     </x:source>
   </reference>
 
   <reference anchor="Semantics">
-    <x:source basename="draft-ietf-httpbis-semantics-latest" href="draft-ietf-httpbis-semantics-latest.xml">
+    <x:source basename="draft-ietf-httpbis-semantics-latest" href="rfc9112.xml">
       <x:defines>Content-Length</x:defines>
       <x:has anchor="GET"/>
       <x:has anchor="abnf.extension"/>
@@ -2250,7 +2250,7 @@
     </front>
     <seriesInfo name="RFC" value="7234"/>
   </reference>
-  
+
   <reference anchor='RFC5861'>
     <front>
       <title abbrev="HTTP stale controls">HTTP Cache-Control Extensions for Stale Content</title>
@@ -2292,7 +2292,7 @@
     <seriesInfo name="BCP" value="26"/>
     <seriesInfo name="RFC" value="8126"/>
   </reference>
-  
+
 </references>
 
 <?BEGININC build/draft-ietf-httpbis-cache-latest.abnf-appendix ?>