--- title: "Describe the process of cache validation using conditional requests." description: "Describe the process of cache validation using conditional requests." author: "Utpal Vishwas" published: 2023-05-23 updated: 2023-05-24 canonical: https://www.mindstick.com/forum/158458/describe-the-process-of-cache-validation-using-conditional-requests category: "cache" tags: ["validation", "cache", "browser-cache"] reading_time: 2 minutes --- # Describe the process of cache validation using conditional requests. [Describe the process](https://www.mindstick.com/forum/160416/describe-the-process-of-obtaining-and-using-a-bearer-token-in-an-oauth-2-0-authorization-flow) of [cache](https://www.mindstick.com/blog/222/clearing-cache-in-asp-dot-net) [validation](https://www.mindstick.com/articles/12234/validation-using-data-annotation-using-entity-framework) using conditional requests. ## Replies ### Reply by Aryan Kumar Cache validation using conditional requests involves the interaction between the client (browser) and the server to determine whether a cached resource is still valid or needs to be revalidated. Here's an overview of the [process](https://yourviews.mindstick.com/story/1525/7-important-factors-that-may-affect-the-learning-process): - **Client Request**: The client sends a request to the server for a particular resource, typically using an HTTP GET method. The request includes headers like **If-Modified-Since** and/or **If-None-Match** to indicate the last known state of the cached resource. - **Server Response**: The server receives the client request and evaluates the provided headers. It checks if the resource has been modified since the specified date (**If-Modified-Since**) or if the resource's entity tag (ETag) matches the provided value (**If-None-Match**). a. If the resource has not been modified: The server responds with a 304 Not Modified status code. This indicates that the cached resource is still valid, and the client can use its local copy without transferring the entire resource again. b. If the resource has been modified: The server responds with a 200 OK status code and includes the updated resource in the response body. Additionally, the server may include new values for headers like **Last-Modified** and **ETag** to be used in subsequent requests. - **Client Action based on Server Response**: a. If the server responds with a 304 Not Modified status code: The client knows that its cached resource is still valid. It can use the local copy from its cache and avoid downloading the entire resource again. This helps to reduce bandwidth usage and improve performance. b. If the server responds with a 200 OK status code: The client receives the updated resource from the server. It can replace the old cached version with the new one and use it for subsequent requests. - **Caching the Updated Resource**: Upon receiving the updated resource, the client may store it in its cache along with the updated headers provided by the server, such as the new **Last-Modified** value or ETag. This allows the client to use the cached resource for future conditional requests. By using conditional requests and cache validation, the client and server can efficiently determine whether a cached resource is still valid, minimizing network traffic and reducing server load while ensuring clients have up-to-date resources. --- Original Source: https://www.mindstick.com/forum/158458/describe-the-process-of-cache-validation-using-conditional-requests Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.