caching.html.en

Apache官方在今天放出产品系列2.2的最新版本2.2.11的源码包 最流行的HTTP服务器软件之一

        <li>Caching must be enabled for this URL. See the <code class="directive"><a href="./mod/mod_cache.html#cacheenable">CacheEnable</a></code> and <code class="directive"><a href="./mod/mod_cache.html#cachedisable">CacheDisable</a></code> directives.</li>

        <li>The response must have a HTTP status code of 200, 203, 300, 301 or 
        410.</li>

        <li>The request must be a HTTP GET request.</li>

        <li>If the request contains an "Authorization:" header, the response
        will not be cached.</li>

        <li>If the response contains an "Authorization:" header, it must
        also contain an "s-maxage", "must-revalidate" or "public" option
        in the "Cache-Control:" header.</li>

        <li>If the URL included a query string (e.g. from a HTML form GET
        method) it will not be cached unless the response includes an
        "Expires:" header, as per RFC2616 section 13.9.</li>

        <li>If the response has a status of 200 (OK), the response must
        also include at least one of the "Etag", "Last-Modified" or
        the "Expires" headers, unless the 
        <code class="directive"><a href="./mod/mod_cache.html#cacheignorenolastmod">CacheIgnoreNoLastMod</a></code> 
        directive has been used to require otherwise.</li>

        <li>If the response includes the "private" option in a "Cache-Control:"
        header, it will not be stored unless the 
        <code class="directive"><a href="./mod/mod_cache.html#cachestoreprivate">CacheStorePrivate</a></code> has been
        used to require otherwise.</li>

        <li>Likewise, if the response includes the "no-store" option in a 
        "Cache-Control:" header, it will not be stored unless the 
        <code class="directive"><a href="./mod/mod_cache.html#cachestorenostore">CacheStoreNoStore</a></code> has been
        used.</li>

        <li>A response will not be stored if it includes a "Vary:" header
        containing the match-all "*".</li>
      </ol>
    

    <h3>What Should Not be Cached?</h3>
      
    
      <p>In short, any content which is highly time-sensitive, or which varies
      depending on the particulars of the request that are not covered by
      HTTP negotiation, should not be cached.</p>

      <p>If you have dynamic content which changes depending on the IP address
      of the requester, or changes every 5 minutes, it should almost certainly
      not be cached.</p>

      <p>If on the other hand, the content served differs depending on the
      values of various HTTP headers, it is possible that it might be possible
      to cache it intelligently through the use of a "Vary" header.</p>
    

    <h3>Variable/Negotiated Content</h3>
      

      <p>If a response with a "Vary" header is received by 
      <code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> when requesting content by the backend it
      will attempt to handle it intelligently. If possible, 
      <code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> will detect the headers attributed in the
      "Vary" response in future requests and serve the correct cached 
      response.</p>

      <p>If for example, a response is received with a vary header such as;</p>

      <div class="example"><p><code>
Vary: negotiate,accept-language,accept-charset
      </code></p></div>

      <p><code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> will only serve the cached content to
      requesters with matching accept-language and accept-charset headers
      matching those of the original request.</p>
    
 
  </div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="security" id="security">Security Considerations</a></h2>
    

    <h3>Authorization and Access Control</h3>
      

      <p>Using <code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> is very much like having a built
      in reverse-proxy. Requests will be served by the caching module unless
      it determines that the backend should be queried. When caching local
      resources, this drastically changes the security model of Apache.</p>

      <p>As traversing a filesystem hierarchy to examine potential
      <code>.htaccess</code> files would be a very expensive operation,
      partially defeating the point of caching (to speed up requests),
      <code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> makes no decision about whether a cached
      entity is authorised for serving. In other words; if
      <code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> has cached some content, it will be served
      from the cache as long as that content has not expired.</p>

      <p>If, for example, your configuration permits access to a resource by IP
      address you should ensure that this content is not cached. You can do this by
      using the <code class="directive"><a href="./mod/mod_cache.html#cachedisable">CacheDisable</a></code>
      directive, or <code class="module"><a href="./mod/mod_expires.html">mod_expires</a></code>. Left unchecked,
      <code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> - very much like a reverse proxy - would cache
      the content when served and then serve it to any client, on any IP
      address.</p>        
    

    <h3>Local exploits</h3>
      

      <p>As requests to end-users can be served from the cache, the cache
      itself can become a target for those wishing to deface or interfere with
      content. It is important to bear in mind that the cache must at all
      times be writable by the user which Apache is running as. This is in 
      stark contrast to the usually recommended situation of maintaining
      all content unwritable by the Apache user.</p>

      <p>If the Apache user is compromised, for example through a flaw in
      a CGI process, it is possible that the cache may be targeted. When
      using <code class="module"><a href="./mod/mod_disk_cache.html">mod_disk_cache</a></code>, it is relatively easy to 
      insert or modify a cached entity.</p>

      <p>This presents a somewhat elevated risk in comparison to the other 
      types of attack it is possible to make as the Apache user. If you are 
      using <code class="module"><a href="./mod/mod_disk_cache.html">mod_disk_cache</a></code> you should bear this in mind - 
      ensure you upgrade Apache when security upgrades are announced and 
      run CGI processes as a non-Apache user using <a href="suexec.html">suEXEC</a> if possible.</p>

    

    <h3>Cache Poisoning</h3>
      

      <p>When running Apache as a caching proxy server, there is also the
      potential for so-called cache poisoning. Cache Poisoning is a broad 
      term for attacks in which an attacker causes the proxy server to 
      retrieve incorrect (and usually undesirable) content from the backend.
      </p>

      <p>For example if the DNS servers used by your system running Apache
      are vulnerable to DNS cache poisoning, an attacker may be able to control
      where Apache connects to when requesting content from the origin server.
      Another example is so-called HTTP request-smuggling attacks.</p>

      <p>This document is not the correct place for an in-depth discussion
      of HTTP request smuggling (instead, try your favourite search engine)
      however it is important to be aware that it is possible to make
      a series of requests, and to exploit a vulnerability on an origin
      webserver such that the attacker can entirely control the content
      retrieved by the proxy.</p>
    
  </div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="filehandle" id="filehandle">File-Handle Caching</a></h2>
    

    <table class="related"><tr><th>Related Modules</th><th>Related Directives</th></tr><tr><td><ul><li><code class="module"><a href="./mod/mod_file_cache.html">mod_file_cache</a></code></li><li><code class="module"><a href="./mod/mod_mem_cache.html">mod_mem_cache</a></code></li></ul></td><td><ul><li><code class="directive"><a href="./mod/mod_file_cache.html#cachefile">CacheFile</a></code></li><li><code class="directive"><a href="./mod/mod_cache.html#cacheenable">CacheEnable</a></code></li><li><code class="directive"><a href="./mod/mod_cache.html#cachedisable">CacheDisable</a></code></li></ul></td></tr></table>

    <p>The act of opening a file can itself be a source of delay, particularly 
    on network filesystems. By maintaining a cache of open file descriptors
    for commonly served files, Apache can avoid this delay. Currently Apache
    provides two different implementations of File-Handle Caching.</p> 

    <h3>CacheFile</h3>
      

      <p>The most basic form of caching present in Apache is the file-handle
      caching provided by <code class="module"><a href="./mod/mod_file_cache.html">mod_file_cache</a></code>. Rather than caching 
      file-contents, this cache maintains a table of open file descriptors. Files 
      to be cached in this manner are specified in the configuration file using
      the <code class="directive"><a href="./mod/mod_file_cache.html#cachefile">CacheFile</a></code> 
      directive.</p>

      <p>The 
      <code class="directive"><a href="./mod/mod_file_cache.html#cachefile">CacheFile</a></code> directive 
      instructs Apache to open the file when Apache is started and to re-use 
      this file-handle for all subsequent access to this file.</p>

      <div class="example"><pre>CacheFile /usr/local/apache2/htdocs/index.html</pre></div>

      <p>If you intend to cache a large number of files in this manner, you 
      must ensure that your operating system's limit for the number of open 
      files is set appropriately.</p>

      <p>Although using <code class="directive"><a href="./mod/mod_file_cache.html#cachefile">CacheFile</a></code>
      does not cause the file-contents to be cached per-se, it does mean
      that if the file changes while Apache is running these changes will
      not be picked up. The file will be consistently served as it was
      when Apache was started.</p>

      <p>If the file is removed while Apache is running, Apache will continue
      to maintain an open file descriptor and serve the file as it was when
      Apache was started. This usually also means that although the file
      will have been deleted, and not show up on the filesystem, extra free
      space will not be recovered until Apache is stopped and the file
      descriptor closed.</p>
    

    <h3>CacheEnable fd</h3>
      

      <p><code class="module"><a href="./mod/mod_mem_cache.html">mod_mem_cache</a></code> also provides its own file-handle 
      caching scheme, which can be enabled via the 
      <code class="directive"><a href="./mod/mod_cache.html#cacheenable">CacheEnable</a></code> directive.</p>

      <div class="example"><pre>CacheEnable fd /</pre></div>

      <p>As with all of <code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> this type of file-handle
      caching is intelligent, and handles will not be maintained beyond
      the expiry time of the cached content.</p>
    
  </div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="inmemory" id="inmemory">In-Memory Caching</a></h2>
    

     <table class="related"><tr><th>Related Modules</th><th>Related Directives</th></tr><tr><td><ul><li><code class="module"><a href="./mod/mod_mem_cache.html">mod_mem_cache</a></code></li><li><code class="module"><a href="./mod/mod_file_cache.html">mod_file_cache</a></code></li></ul></td><td><ul><li><code class="directive"><a href="./mod/mod_cache.html#cacheenable">CacheEnable</a></code></li><li><code class="directive"><a href="./mod/mod_cache.html#cachedisable">CacheDisable</a></code></li><li><code class="directive"><a href="./mod/mod_file_cache.html#mmapstatic">MMapStatic</a></code></li></ul></td></tr></table>
       
    <p>Serving directly from system memory is universally the fastest method
    of serving content. Reading files from a disk controller or, even worse,
    from a remote network is orders of magnitude slower. Disk controllers