HTTP caching for https://en.wikipedia.org

Overview

✅

This resource can be cached.

This response can be cached because of a directive in the Cache-Control header.

✅

This resource has a cache control header.

Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
❌

This resource does not have an entity tag.

HTTP response cache headers

These are the raw caching-related HTTP headers that were returned by the server:
age: 12818
cache-control: private, s-maxage=0, max-age=0, must-revalidate
last-modified: Fri, 17 May 2024 03:36:54 GMT
vary: Accept-Encoding,Cookie,Authorization
🧭

Cache-Control

Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
  • 🔒
    Private
    (RFC)
    The private directive indicates that the response is intended only for a single user and must not be stored in any shared cache. Typically, this means that the response will only be stored in the browser cache.
  • ⏳
    Max Age
    (RFC)

    The max-age directive indicates the response should be considered stale immediately.

    For example, since this response was fetched on May 17, 2024, 7:10:35 AM, it will become stale on May 17, 2024, 7:10:35 AM.

  • ⌛
    Shared Max Age
    (RFC)

    The s-maxage directive indicates the response should be considered stale by shared caches (such as a CDN) immediately.

    For example, since this response was fetched on May 17, 2024, 7:10:35 AM, it will become stale for shared caches on May 17, 2024, 7:10:35 AM.

  • ❗
    Must Revalidate
    (RFC)
    The must-revalidate directive indicates that when the response becomes stale, the cache must revalidate the cached response before it can be used again.
⌛

Age

The Age header indicates how long the response has been in the cache.

Age: 12818

In this case, the response has been in the cache for 12818 seconds (3 hours 33 minutes 38 seconds).

🕒

Last Modified

The Last-Modified header indicates the last time the resource was modified on the origin server.

Last-Modified: Fri, 17 May 2024 03:36:54 GMT

In this case, the resource was last modified on May 17, 2024, 3:36:54 AM (about 4 hours ago).

🔀

Vary

The Vary header indicates which request headers the server response may be dependent on. If any of the listed headers change, then the response may be different. This allows the server to send the correct cached response for each request. For example, ensuring that a client that does not support compression does not receive a cached compressed response.

Vary: Accept-Encoding,Cookie,Authorization

Accept-Encoding: The server response is expected to be different depending on the encodings that the client accepts via the Accept-Encoding header in the request. For example, if the client does not support compression, then the server may send a cached uncompressed response. If the client does support compression, for example, by sending a a Accept-Encoding: gzip header, then the server may send a cached compressed response.

Cookie: The server response will depend on the cookies that the client sends in the request. Typically, this means that the server will cache authenticated responses (since authenticated responses typically include a cookie), but the cached pages will only be served to the same client that sent the request.