Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>An <code>Expires*</code> directive with "modification" as its base refers to the modification time of the file on the server. So if you set, say, "modification plus 2 hours", any browser that requests content within 2 hours after the file is modified (on the server) will cache that content until 2 hours after the file's modification time. And the browser knows when that time is because the server sends an <code>Expires</code> header with the proper expiration time.</p> <p>Let me explain with an example: say your Apache configuration includes the line</p> <pre><code>ExpiresDefault modification plus 2 hours </code></pre> <p>and you have a file <code>index.html</code>, which the <code>ExpiresDefault</code> directive applies to, on the server. Suppose you upload a version of <code>index.html</code> at 9:53 GMT, overwriting the previous existing <code>index.html</code> (if there was one). So now the modification time of <code>index.html</code> is 9:53 GMT. If you were running <code>ls -l</code> on the server (or <code>dir</code> on Windows), you would see it in the listing:</p> <pre><code>-rw-r--r-- 1 apache apache 4096 Feb 18 09:53 index.html </code></pre> <p>Now, with every request, Apache sends the <code>Last-Modified</code> header with the last modification time of the file. Since you have that <code>ExpiresDefault</code> directive, it will also send the <code>Expires</code> header with a time equal to the modification time of the file (9:53) plus two hours. So here is part of what the browser sees:</p> <pre><code>Last-Modified: Wed, 18 Feb 2009 09:53:00 GMT Expires: Wed, 18 Feb 2009 11:53:00 GMT </code></pre> <p>If the time at which the browser makes this request is before 11:53 GMT, the browser will cache the page, because it has not yet expired. So if the user first visits the page at 11:00 GMT, and then goes to the same page again at 11:30 GMT, the browser will see that its cached version is still valid and will not (or rather, is allowed not to) make a new HTTP request.</p> <p>If the user goes to the page a third time at 12:00 GMT, the browser sees that its cached version has now expired (it's after 11:53) so it attempts to validate the page, sending a request to the server with a If-Modified-Since header. A 304 (not modified) response with no body will be returned since the page's date has not been altered since it was first served. Since the expiry date has passed -- the page is 'stale' -- a validation request will be made every subsequent time the page is visited until validation fails.</p> <p>Now, let's pretend instead that you uploaded a new version of the page at 11:57. In this case, the browser's attempt to validate the old version of the page at 12:00 fails and it receives in the response, along with the new page, these two new headers:</p> <pre><code>Last-Modified: Wed, 18 Feb 2009 11:57:00 GMT Expires: Wed, 18 Feb 2009 13:57:00 GMT </code></pre> <p>(The last modification time of the file becomes 11:57 upon upload of the new version, and Apache calculates the expiration time as 11:57 + 2:00 = 13:57 GMT.) </p> <p>Validation (using the more recent date) will not be required now until 13:57. </p> <p>(Note of course that many other things are sent along with the two headers I listed above, I just trimmed out all the rest for simplicity)</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload