1XX warn-codes MAY be generated by a cache only when validating a cached entry. 2xx Warnings that describe some aspect of the entity body or entity headers that is not rectified by a revalidation (for example, a lossy compression of the entity bodies) and which MUST NOT be deleted after a successful revalidation.See section 14.46 for the definitions of the codes themselves.Multiple warnings MAY be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number.For example, a server might provide the same warning with texts in both English and Basque.If a cache receives a response (either an entire response, or a 304 (Not Modified) response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache SHOULD forward it to the requesting client without adding a new Warning (but without removing any existing Warning headers).A cache SHOULD NOT attempt to revalidate a response simply because that response became stale in transit; this might lead to an infinite loop.
Whenever a cache returns a response that is neither first-hand nor "fresh enough" (in the sense of condition 2 in section 13.1.1), it MUST attach a warning to that effect, using a Warning general-header.
When multiple warnings are attached to a response, it might not be practical or reasonable to display all of them to the user.
This version of HTTP does not specify strict priority rules for deciding which warnings to display and in what order, but does suggest some heuristics.
The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see section 13.3).
Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency.
The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases.