8000 Http cache validation rewording by weaverryan · Pull Request #3653 · symfony/symfony-docs · GitHub
[go: up one dir, main page]
Skip to content

Http cache validation rewording #3653

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 19, 2014
Merged

Http cache validation rewording #3653

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 11 additions & 13 deletions book/http_cache.rst
View file
Open in desktop
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 Down Expand Up @@ -578,10 +576,10 @@ automatically sets the ``Response`` status code to 304.

.. note::

The ``If-None-Match`` request header equals the ``ETag`` header of the
last response sent to the client for the particular resource. This is
how the client and server communicate with each other and decide whether
or not the resource has been updated since it was cached.
The cache sets the ``If-None-Match`` header on the request to the ``ETag``
of the original cached response before sending the request back to the
app. This is how the cache and server communicate with each other and
decide whether or 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 Down Expand Up @@ -646,10 +644,10 @@ the ``Response`` will be set to a 304 status code.

.. note::

The ``If-Modified-Since`` request header equals the ``Last-Modified``
header of the last response sent to the client for the particular resource.
This is how the client and server communicate with each other and decide
whether or not the resource has been updated since it was cached.
The cache sets the ``If-Modified-Since`` header on the request to the ``Last-Modified``
of the original cached response before sending the request back to the
app. This is how the cache and server communicate with each other and
decide whether or not the resource has been updated since it was cached.

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