Stores inventory and previous ETag
Backend & Runtime / Knowledge library
HTTP ETag
Identifies a selected resource representation for conditional requests
Why learn HTTP ETag?
It supports cache validation and optimistic concurrency
The problem it solves
It avoids transferring unchanged content while detecting representation changes
Where it came from
HTTP ETag is a networking and web concept that identifies a selected resource representation for conditional requests. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define HTTP ETag and distinguish it from a neighboring concept.
- Choose a realistic task where HTTP ETag is appropriate.
- Identify a failure mode caused by misusing HTTP ETag.
- Interpret a small design or result involving HTTP ETag.
- Explain one tradeoff or limitation of HTTP ETag.
Documentation and sources
- MDN Web Technology Glossary (developer.mozilla.org)
Connect the ideas
Explore next
Real World Example
Optimizing Inventory Catalog Synchronization
A regional logistics provider managing a centralized inventory catalog accessed by hundreds of distributed warehouse tablets.
The business problem
The system suffers from excessive bandwidth consumption and redundant data processing because warehouse tablets repeatedly download the full 5MB inventory JSON file even when no updates have occurred.
How this topic solves it
By implementing HTTP ETags, the server assigns a unique hash to the current state of the inventory file. When a tablet requests the catalog, it sends the previous ETag in an If-None-Match header. If the hash matches the server's current version, the server returns a 304 Not Modified status, signaling the client to continue using its local cache.
- Generate a unique hash (e.g., MD5 or SHA) based on the inventory file content during the server-side build process.
- Configure the server to include the ETag header in the HTTP response for the inventory endpoint.
- Update client-side logic to store the received ETag alongside the cached inventory data.
- Modify subsequent requests to include the If-None-Match header containing the stored ETag value.
- Implement server-side logic to compare the incoming If-None-Match header against the current file hash.
This diagram illustrates the interaction between the warehouse client and the inventory server during a conditional request.
Contains If-None-Match header
Calculates current file hash
Checks if hashes match
Returns 304 or 200 with new data
- Warehouse Tablet → sends → HTTP Request
- HTTP Request → triggers → Inventory Server
- Inventory Server → evaluates → Comparison Logic
- Comparison Logic → determines status → HTTP Response
- HTTP Response → updates cache → Warehouse Tablet
Expected business outcome
Warehouse tablets significantly reduce network traffic and local processing overhead, resulting in a more responsive user interface and lower infrastructure costs.
Limitations and checks
ETags rely on consistent hash generation; if the server cluster generates different hashes for the same content due to load balancing across heterogeneous nodes, the cache will be invalidated unnecessarily. Check this by inspecting the ETag header across multiple server nodes to ensure consistency.