Mar 19, 2014 · Mar 8, 2014
diff --git a/book/http_cache.rst b/book/http_cache.rst
 cache *is* still valid, your application should return a 304 status code
 and no content. This tells the cache that it's ok to return the cached response.

 Under this model, you mainly save bandwidth as the representation is not
 sent twice to the same client (a 304 response is sent instead). But if you
 design your application carefully, you might be able to get the bare minimum
 data needed to send a 304 response and save CPU also (see below for an implementation
 example).
 Under this model, you only save CPU if you're able to determine that the
 cached response is still valid by doing *less* work than generating the whole
 page again (see below for an implementation example).

 .. tip::


 .. note::

    The ``If-None-Match``requestheaderequals the ``ETag`` header of the
 last response sent to the client for theparticular resource. This is
    how theclient and server communicate with each other and decide whether
    or not the resource has been updated since it was cached.
    Thecache sets the``If-None-Match`` headeron therequest to the``ETag``
 of the original cached response before sending therequest back to the
 app. This ishow thecache and server communicate with each other and
 decide whetheror not the resource has been updated since it was cached.

 This algorithm is simple enough and very generic, but you need to create the
 whole ``Response`` before being able to compute the ETag, which is sub-optimal.

 .. note::

    The ``If-Modified-Since``requestheaderequals the ``Last-Modified``
 headerof thelastresponsesent to theclient for the particular resource.
    This is how theclient and server communicate with each other and decide
    whether or not the resource has been updated since it was cached.
    Thecache sets the``If-Modified-Since`` headeron the request to the ``Last-Modified``
    of theoriginal cachedresponsebefore sending therequest back to the
 app.This is how thecache and server communicate with each other and
 decidewhether or not the resource has been updated since it was cached.

 .. index::
   single: Cache; Conditional get
Original file line number	Diff line number	Diff line change
Expand Up		@@ -526,11 +526,9 @@ the application whether or not the cached response is still valid. If the
		cache is still valid, your application should return a 304 status code
		and no content. This tells the cache that it's ok to return the cached response.

		Under this model, you mainly save bandwidth as the representation is not
		sent twice to the same client (a 304 response is sent instead). But if you
		design your application carefully, you might be able to get the bare minimum
		data needed to send a 304 response and save CPU also (see below for an implementation
		example).
		Under this model, you only save CPU if you're able to determine that the
		cached response is still valid by doing less work than generating the whole
		page again (see below for an implementation example).

		.. tip::

Expand DownExpand Up		@@ -578,10 +576,10 @@ automatically sets the ``Response`` status code to 304.

		.. note::

		The ``If-None-Match``requestheaderequals the ``ETag`` header of the
		last response sent to the client for theparticular resource. This is
		how theclient and server communicate with each other and decide whether
		or not the resource has been updated since it was cached.
		Thecache sets the``If-None-Match`` headeron therequest to the``ETag``
		of the original cached response before sending therequest back to the
		app. This ishow thecache and server communicate with each other and
		decide whetheror not the resource has been updated since it was cached.

		This algorithm is simple enough and very generic, but you need to create the
		whole ``Response`` before being able to compute the ETag, which is sub-optimal.
Expand DownExpand Up		@@ -646,10 +644,10 @@ the ``Response`` will be set to a 304 status code.

		.. note::

		The ``If-Modified-Since``requestheaderequals the ``Last-Modified``
		headerof thelastresponsesent to theclient for the particular resource.
		This is how theclient and server communicate with each other and decide
		whether or not the resource has been updated since it was cached.
		Thecache sets the``If-Modified-Since`` headeron the request to the ``Last-Modified``
		of theoriginal cachedresponsebefore sending therequest back to the
		app.This is how thecache and server communicate with each other and
		decidewhether or not the resource has been updated since it was cached.

		.. index::
		single: Cache; Conditional get
Expand Down