What are common HTTP caching headers and their purposes?

What are common HTTP caching headers and their purposes?

• A. Cache-Control, ETag, Last-Modified control caching behavior and validation.
• B. Content-Type, Content-Length, Date handle encoding only.
• C. Last-Modified, Cache-Control, ETag control caching behavior and validation.
• D. Accept, Accept-Language, Accept-Encoding manage request negotiation.

Answer: (C)

Caching relies on specific headers that tell both browsers and intermediate caches how to store a response and when to recheck it. The trio of headers shown here are the most fundamental for managing that behavior: they define how long a cached copy is considered fresh and how to validate it when the client asks for it again. Cache-Control is the workhorse for caching policy. It lets the server specify directives like max-age to indicate how long a response is fresh, and flags such as no-store, no-cache, public, or private to control whether caches should keep or revalidate the content. This header directly guides whether a cached copy can be served without contacting the origin server and under what conditions it should be rechecked. ETag provides a precise version identifier for a resource. When a client stores a cached response with an ETag, it can later present If-None-Match with that same ETag. If the resource hasn’t changed, the server responds with a 304 Not Modified, saving bandwidth by avoiding sending the full body again. ETags support robust validation, including weak versus strong validation semantics to account for minor changes. Last-Modified communicates when the resource was last changed. A client can send If-Modified-Since with that timestamp, and if the resource hasn’t been modified since, the server can again respond with 304 Not Modified. This works well for time-based caching of static-ish content, though it can be less precise if the resource changes without a clear timestamp. The other headers listed don’t primarily govern caching: Content-Type and Content-Length describe the body format and size, Date is about the response timestamp, and Accept-family headers relate to content negotiation rather than caching decisions.

Caching relies on specific headers that tell both browsers and intermediate caches how to store a response and when to recheck it. The trio of headers shown here are the most fundamental for managing that behavior: they define how long a cached copy is considered fresh and how to validate it when the client asks for it again.

Cache-Control is the workhorse for caching policy. It lets the server specify directives like max-age to indicate how long a response is fresh, and flags such as no-store, no-cache, public, or private to control whether caches should keep or revalidate the content. This header directly guides whether a cached copy can be served without contacting the origin server and under what conditions it should be rechecked.

ETag provides a precise version identifier for a resource. When a client stores a cached response with an ETag, it can later present If-None-Match with that same ETag. If the resource hasn’t changed, the server responds with a 304 Not Modified, saving bandwidth by avoiding sending the full body again. ETags support robust validation, including weak versus strong validation semantics to account for minor changes.

Last-Modified communicates when the resource was last changed. A client can send If-Modified-Since with that timestamp, and if the resource hasn’t been modified since, the server can again respond with 304 Not Modified. This works well for time-based caching of static-ish content, though it can be less precise if the resource changes without a clear timestamp.

The other headers listed don’t primarily govern caching: Content-Type and Content-Length describe the body format and size, Date is about the response timestamp, and Accept-family headers relate to content negotiation rather than caching decisions.