Ignore:
Timestamp:
Jul 9, 2012, 4:49:50 PM (7 years ago)
Author:
mnot@…
Message:

most -> many when taking about numbers of implementations; we haven't counted.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r1751 r1752  
    843843      </p>
    844844      <p id="rfc.section.2.p.3">The default <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching
    845          responses to GET, most implementations simply decline other methods and use only the URI as the key.
     845         responses to GET, many implementations simply decline other methods and use only the URI as the key.
    846846      </p>
    847847      <p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated
     
    879879         cache-specific behavior.
    880880      </p>
    881       <p id="rfc.section.3.p.4">Note that, in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration
     881      <p id="rfc.section.3.p.4">Note that, in normal operation, many caches will not store a response that has neither a cache validator nor an explicit expiration
    882882         time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
    883883      </p>
     
    13691369         case-insensitive.
    13701370      </p>
    1371       <p id="rfc.section.7.2.2.3.p.5"> <b>Note:</b> Most HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache response directives with field-names are often
     1371      <p id="rfc.section.7.2.2.3.p.5"> <b>Note:</b> Many HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache response directives with field-names are often
    13721372         handled by implementations as if an unqualified no-cache directive was received; i.e., the special handling for the qualified
    13731373         form is not widely implemented.
     
    14951495      <p id="rfc.section.7.3.p.8">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes
    14961496         are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use
    1497          of 32-bit integers for time values), and most caches will evict a response far sooner than that. Therefore, senders ought
     1497         of 32-bit integers for time values), and many caches will evict a response far sooner than that. Therefore, senders ought
    14981498         not produce them.
    14991499      </p>
Note: See TracChangeset for help on using the changeset viewer.