Web cache: Difference between revisions

Revision as of 07:58, 8 January 2025

Latest revision as of 00:46, 28 August 2025

(32 intermediate revisions by 21 users not shown)

Line 1:

{{short description|System for optimizing the Web}}

A '''Webweb cache''' (or '''HTTP cache''') is a system for optimizing the World Wide Web. It is implemented both client-side and server-side. The caching of multimedia and other files can result in less overall delay when [[web browser|browsing]] the Web.<ref>{{Cite web |last=Fountis |first=Yorgos |date=4 May 2017 |title=How does the browser cache work? |url=https://pressidium.com/blog/2017/browser-cache-work/}}</ref><ref>{{Cite journal |last1=Messaoud |first1=S. |last2=Youssef |first2=H. |date=2009 |title=An analytical model for the performance evaluation of stack-based Webweb cache replacement algorithms |url=https://onlinelibrary.wiley.com/doi/10.1002/dac.1036 |journal=International Journal of Communication Systems |language=en |volume=23 |pages=1–22 |doi=10.1002/dac.1036|s2cid=46507769 |url-access=subscription }}</ref>

==Parts of the system==

===Forward and reverse===

A forward cache is a cache outside the [[web server]]'s network, e.g. in the client's [[web browser]], in an [[ISP]], or within a corporate network.<ref>{{cite web |url=http://www.isaserver.org/tutorials/Understanding-Web-Caching-Concepts-ISA-Firewall.html |title=Understanding Web Caching Concepts for the ISA Firewall |first=Thomas |last=Shinder |access-date=27 February 2011 |date=2 September 2008 |work=[[ISA Server]] |archive-url=https://web.archive.org/web/20110723104247/http://www.isaserver.org/tutorials/Understanding-Web-Caching-Concepts-ISA-Firewall.html |archive-date=23 July 2011 |publisher=TechGenix Ltd.}}</ref> A network-aware forward cache only caches heavily accessed items.<ref name=":0">{{cite journal |url=http://www.research.att.com/export/sites/att_labs/techdocs/TD_7LAUDD.pdf |citeseerx=10.1.1.159.1786 |title=Network-Aware Forward Caching |first1=Jeffrey |last1=Erman |first2=Alexandre |last2=Gerber |first3=Mohammad T. |last3=Hajiaghayi |first4=Dan |last4=Pei |first5=Oliver |last5=Spatscheck |journal=[[AT&T Labs]] |year=2008 |access-date=11 March 2019 |archive-url=https://web.archive.org/web/20110401145549/http://www.research.att.com/export/sites/att_labs/techdocs/TD_7LAUDD.pdf |archive-date=1 April 2011 |pages=291–300}}</ref> A [[proxy server]] sitting between the client and web server can evaluate [[HTTP]] headers and choose whether to store web content.

A reverse cache sits in front of one or more web servers, accelerating requests from the Internet and reducing peak server load. This is usually a [[content delivery network]] (CDN) that retains copies of web content at various points throughout a network.

===HTTP options===

The [[HTTP|Hypertext Transfer Protocol]] (HTTP) defines three basic mechanisms for controlling caches: freshness, validation, and invalidation.<ref>{{cite web |url=http://ws-rest.org/files/03-Link%20Header-based%20Invalidation%20of%20Caches.pdf |title=Using HTTP Link: Header for Gateway Cache Invalidation |access-date=14 June 2013 |first1=Mike |last1=Kelly |first2=Michael |last2=Hausenblas |pages=20 |work=WS-REST |archive-date=10 July 2010 |archive-url=https://web.archive.org/web/20100710072021/http://www.ws-rest.org/files/03-Link%20Header-based%20Invalidation%20of%20Caches.pdf |url-status=dead }}</ref> This is specified in the header of HTTP response messages from the server.

Freshness allows a response to be used without re-checking it on the origin server, and can be controlled by both the server and the client. For example, the Expires response header gives a date when the document becomes stale, and the Cache-Control: max-age directive tells the cache how many seconds the response is fresh for.

Validation can be used to check whether a cached response is still good after it becomes stale. For example, if the response has a Last-Modified header, a cache can make a ''conditional request'' using the If-Modified-Since header to see if it has changed. The [[HTTP ETag|ETag]] (entity tag) mechanism also allows for both strong and weak validation.

Invalidation is usually a side effect of another request that passes through the cache. For example, if a URL associated with a cached response subsequently gets a POST, PUT or DELETE request, the cached response will be invalidated.

Line 21:

==Legality==

In 1998, the [[Digital Millennium Copyright Act]] added rules to the [[United States Code]] ([[Online Copyright Infringement Liability Limitation Act#§ 512(b) System Caching Safe Harbor|17 U.S.C. §: 512]]) that exempts system operators from [[copyright]] liability for the purposes of caching.

==Server-side software==