HTTP caching for https://facebook.com

Overview

❌

This resource might not be cached.

This response cannot be cached because the server responded with no-store in the Cache-Control header.

✅

This resource has a cache control header.

Cache-Control: private, no-cache, no-store, 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:
cache-control: private, no-cache, no-store, must-revalidate
expires: Sat, 01 Jan 2000 00:00:00 GMT
vary: Accept-Encoding
🧭

Cache-Control

Cache-Control: private, no-cache, no-store, 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.
  • ♻️
    No Cache
    (RFC)
    The no-cache directive indicates that this response may be cached, but any cached response must be validated with the origin server before it can be used.
  • 🚫
    No Store
    (RFC)
    The no-store directive indicates that this response must not be stored in any cache.
  • ❗
    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.
🗑️

Expires

The Expires header indicates the time at which the response will expire.

Expires: Sat, 01 Jan 2000 00:00:00 GMT

In this case, the time is in the past, which means the response should be considered stale immediately.

🔀

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

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.