HTTP caching for https://github.com

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: max-age=0, private, must-revalidate
✅

This resource has an entity tag.

ETag: W/"1a1e93e429a66ceffc44e963a42fd597"

Since this response has an entity tag, the entity tag may be used to revalidate a response when it becomes stale. The first time the resource is requested by the client, the response will be cached along with the entity tag. On any subsequent requests, if the cached response is still fresh, then the cached response will be served.

However, if the cached response is stale, then on a subsequent request, the client may send the HTTP header 

If-None-Match: W/"1a1e93e429a66ceffc44e963a42fd597"
to see if the response has changed. If the response has not changed, the server will return a status code of 304 Not Modified to indicate the response is still fresh. Otherwise, if the response has changed, then the server will return the fresh, full response which can be cached again.

HTTP response cache headers

These are the raw caching-related HTTP headers that were returned by the server:
cache-control: max-age=0, private, must-revalidate
etag: W/"1a1e93e429a66ceffc44e963a42fd597"
vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Requested-With, Accept-Language, Sec-Fetch-Site,Accept-Encoding, Accept, X-Requested-With
🧭

Cache-Control

Cache-Control: max-age=0, private, 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 Feb 16, 2026, 9:51:20 PM, it will become stale on Feb 16, 2026, 9:51:20 PM.

  • ❗
    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.
🔀

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: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Requested-With, Accept-Language, Sec-Fetch-Site,Accept-Encoding, Accept, X-Requested-With

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.

Accept-Language: The server response will depend on the language that the client accepts via the Accept-Language header in the request. If the client does not support the language of the cached response, then the server may send a different cached response. However, if the server has a cached response that matches the client's language, then the server may send the cached response. For example, if the client sends Accept-Language: en, then the server may send a cached response in English. If the client sends Accept-Language: fr, then the server may send a cached response in French.