Compare Revisions
HTTP caching
Revision 1142057:
Revision 1142057 by rojazzy on
Revision 1142099:
Revision 1142099 by fscholz on
- Title:
- Main Event>> Watch UFC 205 Alvarez vs McGregor Live Streaming Online Video!!
- HTTP caching
- Slug:
- Web/HTTP/Caching
- Web/HTTP/Caching
- Tags:
- "Caching" "Guide" "HTTP"
- Caching, Guide, HTTP
- Comment:
- Revert to revision of 2016-08-22 06:34:08 by anthony-geoghegan
- Content:
-
Revision 1142057 Revision 1142099 n 8 Main Event>> Watch UFC 205 Alvarez vs McGregor Live S n 8 {{HTTPSidebar}} > treaming Online Video!! t t 10 <p class="summary"> 11 The performance of web sites and applications can be signif > icantly improved by reusing previously fetched resources. Web cac > hes reduce latency and network traffic and thus lessen the time n > eeded to display a representation of a resource. By making use of > HTTP caching, Web sites become more responsive. 12 </p> 13 <h2 id="Different_kinds_of_caches"> 14 Different kinds of caches 15 </h2> 16 <p> 17 Caching is a technique that stores a copy of a given resour > ce and serves it back when requested. When a web cache has a requ > ested resource in its store, it intercepts the request and return > s its copy instead of re-downloading from the originating server. > This achieves several goals: it eases the load of the server tha > t doesn’t need to serve all clients itself, and it improves perfo > rmance by being closer to the client, i.e., it takes less time to > transmit the resource back. For a web site, it is a major compon > ent in achieving high performance. On the other side, it has to b > e configured properly as not all resources stay identical forever > : it is important to cache a resource only until it changes, not > longer. 18 </p> 19 <p> 20 There several kinds of caches: these can be grouped into tw > o main categories: private or shared caches. A <em>shared cache</ > em> is a cache that stores responses for reuse by more than one u > ser. A <em>private cache</em> is dedicated to a single user. This > page will mostly talk about browser and proxy caches, but there > are also gateway caches, CDN, reverse proxy caches and load balan > cers that are deployed on web servers for better reliability, per > formance and scaling of web sites and web applications. 21 </p> 22 <p> 23 <img alt="What a cache provide, advantages/disadvantages of > shared/private caches." src="https://mdn.mozillademos.org/files/ > 13777/HTTPCachtType.png" style="height: 573px; width: 910px;"> 24 </p> 25 <h3 id="Private_browser_caches"> 26 Private browser caches 27 </h3> 28 <p> 29 A private cache is dedicated to a single user. You might ha > ve seen "caching" in your browser's settings already. A browser c > ache holds all documents downloaded via <a href="/en-US/docs/Web/ > HTTP" title="en/HTTP">HTTP</a> by the user. This cache is used to > make visited documents available for back/forward navigation, sa > ving, viewing-as-source, etc. without requiring an additional tri > p to the server. It likewise improves offline browsing of cached > content. 30 </p> 31 <h3 id="Shared_proxy_caches"> 32 Shared proxy caches 33 </h3> 34 <p> 35 A shared cache is a cache that stores responses to be reuse > d by more than one user. For example, an ISP or your company migh > t have set up a web proxy as part of its local network infrastruc > ture to serve many users so that popular resources are reused a n > umber of times, reducing network traffic and latency. 36 </p> 37 <h2 id="Targets_of_caching_operations"> 38 Targets of caching operations 39 </h2> 40 <p> 41 HTTP caching is optional, but reusing a cached resource is > usually desirable. However, common HTTP caches are typically limi > ted to caching responses to {{HTTPMethod("GET")}} and may decline > other methods. The primary cache key consists of the request met > hod and target URI (oftentimes only the URI is used as only GET r > equests are caching targets). Common forms of caching entries are > : 42 </p> 43 <ul> 44 <li>Successful results of a retrieval request: a {{HTTPStat > us(200)}} (OK) response to a {{HTTPMethod("GET")}} request contai > ning a resource like HTML documents, images or files. 45 </li> 46 <li>Permanent redirects: a {{HTTPStatus(301)}} (Moved Perma > nently) response. 47 </li> 48 <li>Error responses: a {{HTTPStatus(404)}} (Not Found) resu > lt page. 49 </li> 50 <li>Incomplete results: a {{HTTPStatus(206)}} (Partial Cont > ent) response. 51 </li> 52 <li>Responses other than {{HTTPMethod("GET")}} if something > suitable for use as a cache key is defined. 53 </li> 54 </ul> 55 <p> 56 A cache entry might also consist of multiple stored respons > es differentiated by a secondary key, if the request is target of > content negotiation. For more details see the information about > the {{HTTPHeader("Vary")}} header <a href="#Varying_responses">be > low</a>. 57 </p> 58 <h2 id="Controlling_caching"> 59 Controlling caching 60 </h2> 61 <h3 id="The_Cache-control_header"> 62 The <code>Cache-control</code> header 63 </h3> 64 <p> 65 The {{HTTPHeader("Cache-Control")}} HTTP/1.1 general-header > field is used to specify directives for caching mechanisms in bo > th requests and responses. Use this header to define your caching > policies with the variety of directives it provides. 66 </p> 67 <h4 id="No_cache_storage_at_all"> 68 No cache storage at all 69 </h4> 70 <p> 71 The cache should not store anything about the client reques > t or server response. A request is sent to the server and a full > response is downloaded each and every time. 72 </p> 73 <pre> 74 Cache-Control: no-store 75 Cache-Control: no-cache, no-store, must-revalidate 76 </pre> 77 <h4 id="No_caching"> 78 No caching 79 </h4> 80 <p> 81 A cache will send the request to the origin server for vali > dation before releasing a cached copy. 82 </p> 83 <pre> 84 Cache-Control: no-cache 85 </pre> 86 <h4 id="Private_and_public_caches"> 87 Private and public caches 88 </h4> 89 <p> 90 The "public" directive indicates that the response may be c > ached by any cache. This can be useful, if pages with HTTP authen > tication or response status codes that aren't normally cacheable, > should now be cached. On the other hand, "private" indicates tha > t the response is intended for a single user only and must not be > stored by a shared cache. A private browser cache may store the > response in this case. 91 </p> 92 <pre> 93 Cache-Control: private 94 Cache-Control: public 95 </pre> 96 <h4 id="Expiration"> 97 Expiration 98 </h4> 99 <p> 100 The most important directive here is "<code>max-age=<sec > onds></code>" which the maximum amount of time a resource will > be considered fresh. Contrary to {{HTTPHeader("Expires")}}, this > directive is relative to the time of the request. For the files > in the application that will not change, you can usually add aggr > essive caching. This includes static files such as images, CSS fi > les and JavaScript files, for example. 101 </p> 102 <p> 103 For more details, see also the <a href="#Freshness">Freshne > ss</a> section below. 104 </p> 105 <pre> 106 Cache-Control: max-age=31536000 107 </pre> 108 <h4 id="Validation"> 109 Validation 110 </h4> 111 <p> 112 When using the "<code>must-revalidate</code>" directive, th > e cache must verify the status of the stale resources before usin > g it and expired ones should not be used. For more details, see t > he <a href="#Cache_validation">Validation</a> section below. 113 </p> 114 <pre> 115 Cache-Control: must-revalidate 116 </pre> 117 <h3 id="The_Pragma_header"> 118 The <code>Pragma</code> header 119 </h3> 120 <p> 121 {{HTTPHeader("Pragma")}} is a HTTP/1.0 header, is not speci > fied for HTTP responses and is therefore not a reliable replaceme > nt for the general HTTP/1.1 <code>Cache-Control</code> header, al > though it does behave the same as <code>Cache-Control: no-cache</ > code>, if the <code>Cache-Control</code> header field is omitted > in a request. Use <code>Pragma</code> only for backwards compatib > ility with HTTP/1.0 clients. 122 </p> 123 <h2 id="Freshness"> 124 Freshness 125 </h2> 126 <p> 127 Once a resource is stored in a cache, it could theoreticall > y be served by the cache forever. Caches have finite storage so i > tems are periodically removed from storage. This process is calle > d <em>cache eviction</em>. On the other side, some resources may > change on the server so the cache should be updated. As HTTP is a > client-server protocol, servers can't contact caches and clients > when a resource change; they have to communicate an expiration t > ime for the resource. Before this expiration time, the resource i > s <em>fresh</em>; after its expiration time, the resource if <em> > stale</em>. Eviction algorithms often privileges fresh resources > over stale resources. Note that a stale resource is not evicted o > r ignored; when the cache receives a request for a stale resource > , it forwards this requests with a {{HTTPHeader("If-None-Match")} > } to check if it isn't in fact still fresh. If so, the server ret > urns a {{HTTPStatus("304")}} (Not Modified) header without sendin > g the body of the requested resource, saving some bandwidth. 128 </p> 129 <p> 130 Here is an example of this process with a shared cache prox > y: 131 </p> 132 <p> 133 <img alt="Show how a proxy cache acts when a doc is not cac > he, in the cache and fresh, in the cache and stale." src="https:/ > /mdn.mozillademos.org/files/13771/HTTPStaleness.png" style="heigh > t: 910px; width: 822px;"> 134 </p> 135 <p> 136 The freshness lifetime is calculated based on several heade > rs. If a "<code>Cache-control: max-age=N</code>" header is specif > ied, then the freshness lifetime is equal to N. If this header is > not present, which is very often the case, it is checked if an { > {HTTPHeader("Expires")}} header is present. If an <code>Expires</ > code> header exists, then its value minus the value of the {{HTTP > Header("Date")}} header determines the freshness lifetime. Finall > y, if neither header is present, look for a {{HTTPHeader("Last-Mo > dified")}} header. If this header is present, then the cache's fr > eshness lifetime is equal to the value of the <code>Date</code> h > eader minus the value of the <code>Last-modified</code> header di > vided by 10.<br> 137 The expiration time is computed as follows: 138 </p> 139 <pre> 140 expirationTime = responseTime + freshnessLifetime - currentAge 141 </pre> 142 <p> 143 where <code>responseTime</code> is the time at which the re > sponse was received according to the browser. 144 </p> 145 <h3 id="Revved_resources"> 146 Revved resources 147 </h3> 148 <p> 149 The more we use cached resources, the better the responsive > ness and the performance of a Web site will be. To optimize this, > good practices recommend to set expiration times as far in the f > uture as possible. This is possible on resources that are regular > ly updated, or often, but is problematic for resources that are r > arely and infrequently updated. They are the resources that would > benefit the most from caching resources, yet this make them very > difficult to update. This is typical of the technical resources > included and linked from each Web pages: JavaScript and CSS files > change infrequently, but when they change you want them to be up > dated quickly. 150 </p> 151 <p> 152 Web developers invented a technique that Steve Sounders cal > led <em>revving</em><sup><a href="https://www.stevesouders.com/bl > og/2008/08/23/revving-filenames-dont-use-querystring/">[1]</a></s > up>. Infrequently updated files are named in specific way: in the > ir URL, usually in the filename, a revision (or version) number i > s added. That way each new revision of this resource is considere > d as a resource on its own that <em>never</em> changes and that c > an have an expiration time very far in the future, usually one ye > ar or even more. In order to have the new versions, all the links > to them must be changed, that is the drawback of this method: ad > ditional complexity that is usually taken care by the tool chain > used by Web developers. When the infrequently variable resources > change they induce an additional change to often variable resourc > es. When these are read, the new versions of the others are also > read. 153 </p> 154 <p> 155 This technique has an additional benefit: updating two cach > ed resources at the same time will not lead to the situation wher > e the out-dated version of one resource is used in combination wi > th the new version of the other one. This is very important when > web sites have CSS stylesheets or JS scripts that have mutual dep > endencies, i.e., they depend on each other because they refer to > the same HTML elements. 156 </p> 157 <p> 158 <img alt="" src="https://mdn.mozillademos.org/files/13779/H > TTPRevved.png"> 159 </p> 160 <p> 161 The revision version added to revved resources doesn't need > to be a classical revision string like 1.1.3, or even a monotono > usly growing suite of number. It can be anything that prevent col > lisions, like a hash or a date. 162 </p> 163 <h2 id="Cache_validation"> 164 Cache validation 165 </h2> 166 <p> 167 Revalidation is triggered when the user presses the reload > button. It is also triggered under normal browsing if the cached > response includes the "<code>Cache-control: must-revalidate</code > >" header. Another factor is the cache validation preferences in > the <code>Advanced->Cache</code> preferences panel. There is a > n option to force a validation each time a document is loaded. 168 </p> 169 <p> 170 When a cached documents expiration time has been reached, i > t is either validated or fetched again. Validation can only occur > if the server provided either a <em>strong validator</em> or a < > em>weak validator</em>. 171 </p> 172 <h3 id="ETags"> 173 ETags 174 </h3> 175 <p> 176 The {{HTTPHeader("ETag")}} response header is an <em>opaque > -to-the-useragent</em> value that can be used as a strong validat > or. That means that a HTTP user-agent, such as the browser, does > not know what this string represents and can't predict what its v > alue would be. If the <code>ETag</code> header was part of respon > se for a resource, the client can issue an {{HTTPHeader("If-None- > Match")}} in the header of future requests – in order to validate > the cached resource. 177 </p> 178 <p> 179 The {{HTTPHeader("Last-Modified")}} response header can be > used as a weak validator. It is considered weak because it only h > as 1-second resolution. If the <code>Last-Modified</code> header > is present in a response, then the client can issue an {{HTTPHead > er("If-Modified-Since")}} request header to validate the cached d > ocument. 180 </p> 181 <p> 182 When a validation request is made, the server can either ig > nore the validation request and response with a normal {{HTTPStat > us(200)}} <code>OK</code>, or it can return {{HTTPStatus(304)}} < > code>Not Modified</code> (with an empty body) to instruct the bro > wser to use its cached copy. The latter response can also include > headers that update the expiration time of the cached document. 183 </p> 184 <h2 id="Varying_responses"> 185 Varying responses 186 </h2> 187 <p> 188 The {{HTTPHeader("Vary")}} HTTP response header determines > how to match future request headers to decide whether a cached re > sponse can be used rather than requesting a fresh one from the or > igin server. 189 </p> 190 <p> 191 When a cache receives a request that can be satisfied by a > cached response that has a <code>Vary</code> header field, it mus > t not use that cached response unless all header fields as nomina > ted by the <code>Vary</code> header match in both the original (c > ached) request and the new request. 192 </p> 193 <p> 194 <img alt="The Vary header leads cache to use more HTTP head > ers as key for the cache." src="https://mdn.mozillademos.org/file > s/13769/HTTPVary.png" style="height: 817px; width: 752px;"> 195 </p> 196 <p> 197 This can be useful for serving content dynamically, for exa > mple. When using the <code>Vary: User-Agent</code> header, cachin > g servers should consider the user agent when deciding whether to > serve the page from cache. If you are serving different content > to mobile users, it can help you to avoid that a cache may mistak > enly serve a desktop version of your site to your mobile users. I > n addition, it can help Google and other search engines to discov > er the mobile version of a page, and might also tell them that no > <a href="https://en.wikipedia.org/wiki/Cloaking">Cloaking</a> is > intended. 198 </p> 199 <pre> 200 Vary: User-Agent 201 </pre> 202 <p> 203 Because the {{HTTPHeader("User-Agent")}} header value is di > fferent ("varies") for mobile and desktop clients, caches will no > t be used to serve mobile content mistakenly to desktop users or > vice versa. 204 </p> 205 <h2 id="See_also"> 206 See also 207 </h2> 208 <ul> 209 <li> 210 <a href="https://tools.ietf.org/html/rfc7234">RFC 7234: H > ypertext Transfer Protocol (HTTP/1.1): Caching</a> 211 </li> 212 <li> 213 <a href="https://www.mnot.net/cache_docs">Caching Tutoria > l – Mark Nottingham</a> 214 </li> 215 <li> 216 <a href="https://developers.google.com/web/fundamentals/p > erformance/optimizing-content-efficiency/http-caching">HTTP cachi > ng – Ilya Grigorik</a> 217 </li> 218 <li> 219 <a href="https://redbot.org/">RedBot</a>, a tool to check > your cache-related HTTP headers. 220 </li> 221 </ul>