HTTP ETags Explained: Revalidate a Public Course Catalogue

Practical Web Development — Lesson 8 of 10 · Advanced

A public course catalogue may change only a few times a day, but visitors can request it repeatedly. HTTP validators let a client ask whether its cached representation is still current. An ETag identifies a version of a representation; a conditional request can avoid downloading the same body again.

Follow one revalidation exchange

These are illustrative HTTP messages, not JavaScript to paste into Blogger. The server must generate a validator that changes when the selected representation changes.

GET /api/courses HTTP/1.1
Host: example.test

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=60
ETag: "catalogue-v7"

[{"id":"html","title":"HTML fundamentals"}]

# After the cached response becomes stale:
GET /api/courses HTTP/1.1
Host: example.test
If-None-Match: "catalogue-v7"

HTTP/1.1 304 Not Modified
Cache-Control: public, max-age=60
ETag: "catalogue-v7"

The 304 response has no catalogue body. The client can reuse the stored representation and update its cache metadata. If the catalogue changed to version eight, the server would send a 200 response with the new body and new ETag instead. A normal browser cache may handle this exchange automatically; application code does not always see a raw 304 response.

Do not confuse freshness with validation

Max-age describes how long a response can be reused as fresh under the caching rules. An ETag lets the client validate a stored response later. Setting no-cache means a stored response requires validation before reuse; it does not mean “never store.” Use no-store when the response must not be stored by caches.

Choose the correct representation boundary

If content differs by language or encoding, the cache must distinguish the relevant variants, and validators must be correct for the selected representation. An ETag that stays constant while the body changes can cause clients to keep stale data. A timestamp with insufficient precision can miss rapid updates. Prefer your server framework's well-tested conditional request support instead of casually comparing raw header strings.

Separate public and private data

The public catalogue and a learner's private progress should not share the same caching policy. Do not mark an authenticated progress response public merely because the catalogue example does. Review CDN configuration, authentication and response headers together. A fast response is not a success if it exposes another learner's information.

Observe the network

  1. Open the network panel and keep normal caching enabled.
  2. Load a public endpoint and inspect Cache-Control and ETag.
  3. Repeat after its freshness window and look for conditional request headers.
  4. Change the catalogue and verify a new body and validator arrive.

Developer tools can disable cache while open, which changes the experiment. Record that setting when comparing results.

Practice

Write a cache policy for course descriptions, thumbnail files and private progress. For each, specify who may cache it, how long stale content is acceptable and how updates become visible. Explain why one policy cannot safely cover all three.

Continue learning

Review our semantic HTML project, JavaScript course filter and course platform architecture.

Reference: Technical documentation for this lesson. Examples are learning exercises; test them in your environment.

Comments

Popular posts from this blog

What Is Multimedia? Examples and a Beginner Course Guide

Internet vs World Wide Web: HTML and Multimedia Explained

Video in Multimedia: Formats, Compression and Captions