{"id":54,"date":"2002-08-01T00:00:26","date_gmt":"2002-08-01T10:00:26","guid":{"rendered":"http:\/\/u20.freesoft.org\/blogs\/soapbox\/?p=54"},"modified":"2017-11-22T18:25:24","modified_gmt":"2017-11-23T04:25:24","slug":"standardized-caching-of-dynamic-web-content","status":"publish","type":"post","link":"https:\/\/www.freesoft.org\/blogs\/soapbox\/standardized-caching-of-dynamic-web-content\/","title":{"rendered":"Standardized caching of dynamic web content"},"content":{"rendered":"
\r\nInternet Engineering Task Force\r\nINTERNET-DRAFT\r\nExpires March 2003\r\n\r\n\r\n\r\n             Standardized caching of dynamic web content\r\n\r\n\t\t\t   by Brent Baccala\r\n\t\t\t baccala@freesoft.org\r\n\t\t\t     August, 2002\r\n\r\n\r\n\r\n\r\nThis document is an Internet-Draft and is subject to all provisions of\r\nSection 10 of RFC2026.\r\n\r\nInternet-Drafts are working documents of the Internet Engineering Task\r\nForce (IETF), its areas, and its working groups.  Note that other\r\ngroups may also distribute working documents as Internet-Drafts.\r\n\r\nInternet-Drafts are draft documents valid for a maximum of six months\r\nand may be updated, replaced, or obsoleted by other documents at any\r\ntime.  It is inappropriate to use Internet-Drafts as reference\r\nmaterial or to cite them other than as \"work in progress.\"\r\n\r\nThe list of current Internet-Drafts can be accessed at\r\nhttp:\/\/www.ietf.org\/1id-abstracts.html\r\n\r\nThe list of Internet-Draft Shadow Directories can be accessed at\r\nhttp:\/\/www.ietf.org\/shadow.html\r\n\r\n\r\n\r\n\t\t\t       ABSTRACT\r\n\r\n   Summarizes the present state of web caching technology.  Points out\r\n   the need for caching dynamic web sites, and the inadequacy of\r\n   present caching technology for anything but static sites.  Proposes\r\n   the adoption of Java servlets, cryptographically signed Web\r\n   Application Archives (WARs), and LDAP as standards for dynamic web\r\n   caching, using an expanded interpretation of existing DNS standards\r\n   to locate and authenticate cached information.\r\n\r\nThe World Wide Web (WWW), probably the most successful networking\r\ntechnology of the 1990s, provides a global graphical user interface\r\n(GUI) that presently dominates the Internet.  The current design of\r\nthe web has an overwhelming advantage over older connection-oriented\r\nprotocols such as TELNET or X Windows.  The web is data-oriented, not\r\nconnection-oriented, or is at least more so than conventional\r\nprotocols.  A web page is completely defined by a block of HTML, which\r\nis downloaded in a single operation.  Highlighting of links, typing\r\ninto fill-in forms, scrolling - all are handled locally by the client.\r\nRather than requiring a connection to remain open to communicate mouse\r\nand keyboard events back to the server, the entire behavior of the\r\npage is described in the HTML.\r\n\r\nThe advent of web caches changes this paradigm subtly, but\r\nsignificantly.  In a cached environment, the primitive operation in\r\ndisplaying a web page is no longer an end-to-end connection to the web\r\nserver, but the delivery of a named block of data, specifically the\r\nHTML source code of a web page, identified by its URL.  The presence\r\nof a particular DNS name in the URL does not imply that a connection\r\nwill be made to that host to complete the request.  If a local cache\r\nhas a copy of the URL, typically because it was requested and\r\nretrieved earlier, it will simply be delivered, without any wide area\r\noperations.  Only if the required data is missing from the local\r\ncaches will wide area network connections be opened to retrieve the\r\ndata.  Generally, caches store content based on the URLs, and\r\nsometimes use inter-cache protocols such as ICP to communicate to\r\nother caches which URLs they possess.  A variant on this scheme is the\r\nweb replica, in which an entire web site, or some logical subsection\r\nof one, is duplicated elsewhere.\r\n\r\nExperience with web caches demonstrates that they provide several\r\nbenefits.  First, the bandwidth requirements of a heavily cached,\r\ndata-oriented network is much less than an uncached,\r\nconnection-oriented network.  A cached copy of a web page, stored\r\nanywhere on the network, works as well as the original.  As the\r\nnetwork becomes more heavily cached, fewer and more localized\r\nconnections are required to carry out various operations, reducing\r\noverall network load.  Furthermore, cached or replicated web sites are\r\nmore fault-tolerant, since their data can still be accessed even if\r\nthe origin server fails or the network becomes partitioned.  A general\r\nconsensus seems to exist that caching improves network performance;\r\nmore widespread adoption of web caching has been limited by technical\r\nchallenges.\r\n\r\nOne of the greatest of these challenges is caching dynamic content,\r\nthat is, pages generated by software as they are requested, such as\r\nresponse pages to search requests.  Presently, web caching protocols\r\nprovide means for including meta information, in either HTTP or HTML,\r\nthat inhibits caching on dynamic pages, and thus forces a connection\r\nback to the origin server.  While this works, it negates the\r\nadvantages of caching.  To maintain the flexibility of dynamic content\r\nin a cached network, we need to lose the end-to-end connection\r\nrequirement and this seems to imply caching the programs that generate\r\nthe dynamic web pages.  While cryptographic techniques for verifying\r\nthe integrity of data have been developed and are increasingly widely\r\ndeployed, no techniques are known for verifying the integrity of\r\nprogram execution on an untrusted host, such as a web cache.  Barring a\r\ntechnological breakthrough, it seems impossible for a cache to\r\nreliably run the programs required to generate dynamic content.  The\r\nonly remaining solution is to cache the programs themselves (in the\r\nform of data), and let the clients run the programs and generate the\r\ndynamic content themselves.  Thus, what's needed is a standard for\r\ntransporting and storing programs in the form of data.\r\n\r\nA closely related problem arises when replicating a web site.  A\r\nsignificant hurdle for building web replicas is the lack of a standard\r\nto deliver the executable components that underlay dynamic content.\r\nWhile scripting languages such as Perl and Python are readily\r\navailable, installing a web replica almost invariably requires\r\ntweaking configuration files and downloading various additional\r\npackages needed by the scripts.  Without a standard for dynamic\r\ncontent, there is simply no way to automatically replicate a web site,\r\nunless its content is completely static.  Also, running a Perl script\r\ntypically provides little in the way of security.  Either the script\r\nmust be carefully reviewed by the installer, or the author must simply\r\nbe trusted.\r\n\r\nJava \"servlets\" are a step in the right direction, since they provide\r\na CGI-type capability that enables a web cache to present dynamic\r\ncontent without a connection to the origin server.  Since they are\r\nJava-based, they provide solutions to the security issues that\r\nsurround something like Perl.  Java's security model provides the\r\ntools to limit servlet access to the host system.  This allows a\r\ncached servlet to reference a collection of Java classes it needs for\r\nproper operation, and have them loaded automatically without the need\r\nof manual intervention.\r\n\r\nPart of the Java servlet specification is WAR (Web Application\r\nArchive), an extension to JAR that provides Java servlets, HTML and\r\nJSP pages, and XML meta data all packaged up into a single archive\r\nfile to provide a \"web application\".  In the current implementation,\r\nthe server administrator \"installs\" the WAR at a particular URL by\r\nloading it onto a Java servlet-enabled web server.  If the WAR format\r\nwere altered slightly to include, perhaps in the XML meta data, a\r\n\"master\" URL, and the servlet-enabled web server were to function more\r\nas a proxy, handling requests locally if it possessed a valid WAR,\r\npassing them along otherwise, this would be a big step in the right\r\ndirection.  Ultimately, though, to get away from having to trust a\r\nproxy to execute WAR content, the client has to execute the content\r\nitself.  Servers and caches should eventually do nothing but hand out\r\ndata, and the responsibly for executing it should fall exclusively to\r\nthe client, not the cache.  For the time being, using a local, trusted\r\ncache will enable experimentation with these ideas without changing\r\nclient implementations.\r\n\r\nUsing WARs for application caching, instead of the manual installation\r\nof applications that they were originally designed for, presents some\r\nchallenges.  In addition to adding XML entries to the WAR to specify\r\nthe base URL, additional entries may be needed to specify a time\r\ninterval for which the WAR is valid, as well as whether an outdated\r\nWAR can continue to be used if a more recent one can't be retrieved.\r\nFurthermore, Java servlets typically run with a fairly trusted\r\nsecurity model.  A more restricted security environment should be used\r\nfor cached WARs downloaded from foreign web sites.\r\n\r\nAlso, provisions should be made for incremental updating of the WAR,\r\nsince only a portion of a large archive may change in an update.\r\nAlthough protocols such as rsync have been developed to incrementally\r\nupdate files, they have limitations.  Rsync depends on changes being\r\nlocalized within the file.  Files with small changes spread widely\r\nacross them, such as search engine indices, don't update well using\r\nrsync, suggesting that something more flexible would be preferred.\r\nSince the WAR is already Java-based, perhaps specifying Java classes,\r\nor pointers to Java classes, in the WAR for performing incremental WAR\r\nupdates would provide a powerful mechanism for tailoring the update\r\nmechanism to the type of files contained in the archive.  Perhaps many\r\nof these functions, like deciding the validity of a WAR, should be\r\nspecified via Java classes, for maximum flexibility.\r\n\r\nSecurity and authentication are major concerns, especially in a cached\r\nenvironment.  In this case, some protocols exist to provide\r\nauthentication services, yet have many outstanding issues.  Some are\r\nnot widely deployed - DNS key services, for example.  The most widely\r\ndeployed solution - X.509 certificates - has been priced and managed\r\ninto a realm when only e-business sites can realistically justify\r\ntheir costs.  Web security can't be just for those who can and will\r\nshell out hundreds of dollars for certificates that keep expiring.  In\r\na heavily cached environment, it's easier than ever to spoof\r\nsomebody's URLs, and X.509-based authentication needs to be in place\r\nfor 99% of the net's web sites, not 1% of them.  Standards exist\r\nfor storing public keys in DNS (KEY and CERT resource records),\r\nwhich can be used to validate signed JAR\/WAR files.\r\n\r\nFor more rapid response time, the Range: header could be used to\r\nretrieve first the WAR file's table of contents, then the compressed\r\ndata of the particular URL, resulting in a retrieval time comparable\r\nto straight HTTP, ignoring the search time required to find the cache\r\nitem to begin with and the compilation\/startup time of any dynamic\r\ncode (both of which may be significant).  Of course, in addition to\r\nsuch a \"partial retrieval\", a cache could do a \"full retrieval\",\r\nobtaining the entire packaged WAR and begin sharing it with other\r\ncaches.  The decision of how to choose between partial and full\r\nretrieval is left \"for further study\", in other words, the user has to\r\nmake those decisions manually until we figure it out better.  Napster\r\nhas demonstrated that letting the users make caching decisions\r\nmanually is workable, so long as the cache items are reasonably sized\r\n(not too large or too small) and well labeled.\r\n\r\nA major choice remains, that of the search protocol to find the cached\r\nWARs.  Mainstream caching research tends to largely ignore the most\r\nsuccessful example of a cached network service - Napster and its\r\nvarious spinoffs, most notably Gnutella, which seem to go by the\r\nbuzzword peer-to-peer file sharing, or P2P.  For example, RFC 3040,\r\n\"Internet Web Replication and Caching Taxonomy\", a January 2001\r\ndocument discussing \"protocols, both open and proprietary, employed in\r\nweb replication and caching today,\" never mentions the word \"Napster\".\r\nSince peer-to-peer was designed to share music and not HTML documents,\r\nthe oversight can be forgiven, but this point needs to be made and\r\nmade strongly - Napster, Gnutella, and friends _are_ caching services,\r\nand by far the most successful ones built to date.  Peer-to-peer\r\nseems to be the way to go.\r\n\r\nThe legal problems of Napster and the highly critical reception of the\r\ntechnical community to Gnutella suggest against either of these\r\nprotocols.  At present, LDAP seems the best choice, due to its\r\nmaturity as a protocol, the widespread availability of both client and\r\nserver implementations, and its straightforward application to the\r\nproblem at hand.  The only serious issue surrounding LDAP is the lack\r\nof a standardized means for server location in a P2P environment, the\r\ncritical issue swirling around Gnutella.\r\n\r\nI suggest dealing with both the security issues and the P2P server\r\nlocation issue through a simple solution: assume the correct operation\r\nof DNS even in the face of server failure.  This allows site\r\nadministrators to use resource records to specify both a set of LDAP\r\nservers to search for WARs, as well as cryptographic keys to verify\r\nthe contents of those WARs once they are retrieved.  Although this\r\nmakes proper operation of a cached web site dependent on proper DNS\r\noperation, this should presently be a minor tradeoff, since proper web\r\nsite operation is already based on DNS, and DNS had proven to be one\r\nof the most reliable of the Internet technologies.\r\n\r\nThus, to enable dynamic web caching, as outlined in this document, a\r\nweb server administrator should add two kinds of additional resource\r\nrecords to the web server's DNS records.  First, a set of SRV records\r\nshould specify a set of LDAP servers, any of which can be searched for\r\nthe web site's WARs.  These LDAP servers should form a replicated set,\r\nso that a response from any one of them should be considered a\r\ncomplete answer by a client.  These servers may also allow arbitrary,\r\nunauthenticated web caches to add entries to the LDAP directory when\r\nthey elect to cache one or more of a site's WARs.  Since clients are\r\nexpected to cryptographically verify a WAR upon retrieving it,\r\nallowing unauthenticated additions to an LDAP directory should not\r\nallow site spoofing, but a large number of bogus WAR entries could\r\nform the basis for a denial of service attack.  A benefit of this\r\nproposal is that site administrators can select sets of LDAP servers\r\nbased on their own policies.  At least one set of publicly updatable,\r\nreplicated, highly available LDAP servers should exist for the use of\r\nsmall web sites without the capability to set up large replicated\r\ninstallations.\r\n\r\nThe DNS SRV records in question can simply be the \"_ldap._tcp\" records\r\nmentioned as a example in RFC 2782.  Thus, to specify LDAP servers for\r\nregistering or searching WARs for \"www.freesoft.org\" URLs, DNS SRV\r\nrecords should be added for \"_ldap._tcp.www.freesoft.org\".  In the\r\ncase of the publicly available LDAP servers mentioned above, and other\r\nLDAP servers used by multiple web sites, careful consideration should\r\nbe given to making the \"_ldap._tcp\" record a CNAME pointing to a set\r\nof SRV records, allowing the LDAP server administrators to modify the\r\nlist of LDAP servers without requiring changes to every web site using\r\nthe service.  Furthermore, the use of \"_ldap\" for this new service may\r\nconflict with existing LDAP applications.  Another name, perhaps\r\n\"_webldap\" might be a better choice.  Another possibility would be to\r\nuse both names, specifying that \"_webldap\" would take precedence over\r\n\"_ldap\" for this application, and the \"_ldap\" records would be used\r\nonly if \"_webldap\" records did not exist.  This would allow the\r\nInternet community to use \"_webldap\" if needed, expecting that this\r\nname would simply fall into disuse if only \"_ldap\" is really needed.\r\n\r\nAlso, the web administrator will need to add at least one KEY record\r\nspecifying a public key that must be used by clients to validate the\r\nintegrity of a retrieved WAR.  Due to the ease with which a bogus WAR\r\ncould be registered with a public LDAP service, this is regarded as a\r\ncritical step.  The administrator must provide the KEY record and the\r\nclient must validate it before trusting the WAR.  Unsigned WARs are\r\ninvalid and so are DNS entries without KEY records - both the SRV and\r\nKEY records must be present.  Perhaps a CERT record would be a better\r\nchoice than KEY, also, we need to consider how multiple KEY or CERT\r\nrecords should be handled by a client.\r\n\r\nSo, for example, consider the \"www.freesoft.org\" web site, originally\r\nspecified in DNS like this:\r\n\r\n   $ORIGIN freesoft.org.\r\n\r\n   www\t\tIN  CNAME          sparky.freesoft.org.\r\n   sparky\tIN  A\t           4.22.66.35\r\n\r\nTo add WAR-based caching of dynamic web content for this site, records\r\nsimilar to these should be added:\r\n\r\n   www\t\t\tIN  KEY\t           --- public key goes here ---\r\n   _ldap._tcp.www\tIN  CNAME          ldapsrv\r\n   ldapsrv\t\tIN  SRV  0 0 389   ldap1.freesoft.org.\r\n   ldapsrv\t\tIN  SRV  0 0 389   ldap2.freesoft.org.\r\n   ldapsrv\t\tIN  SRV  0 0 389   ldap3.freesoft.org.\r\n\r\nRetaining the original CNAME record would require moving the KEY\r\nrecord to \"sparky\", since CNAME records can't co-exist with other\r\nrecords.  An alternative to retaining the original server\r\nconfiguration would be to replace the \"www\" entries with A records\r\npointing to a set of web caches.  Thus, any legacy client trying to\r\nretrieve a page from this web site would be automatically directed to\r\na web cache.  It'd be convenient to specify a CNAME for \"www\" pointing\r\nto a set of A records for the web caches, but of course this would\r\npreclude a unique KEY record for the server.  Perhaps the KEY record\r\nshould appear on a unique name, such as \"_key.www\", specifically to\r\npermit this feature.  The interaction of CNAME with the other resource\r\nrecords requires more consideration.\r\n\r\nRFC 2535 specifies the structure of KEY records, and recommends the\r\nassignment of new Protocol Octet values for new applications.  If\r\nthis proposal is adopted, IANA should assign a new Protocol Octet\r\nvalue for validation of dynamic web archives.\r\n\r\nA typical client request would follow these steps:\r\n\r\n1. Client is configured to use a local web cache, or, attempts a\r\n   standard retrieval and gets A records for web caches\r\n\r\n2. Client sends request to web cache\r\n\r\n3. Web cache does DNS lookup and gets KEY and SRV records\r\n\r\n4. Web cache does LDAP search for the URL and gets a list of WAR\r\n   directory entries, placed there by other (remote) web caches\r\n\r\n5. Web cache picks an entry, contacts the remote cache using HTTP\r\n   and either retrieves the entire WAR or just the parts it needs\r\n   to serve the requested URL\r\n\r\n6. Web cache validates that WAR was signed using the private key\r\n   corresponding to the public key retrieved in the DNS KEY record,\r\n   and recurses to step 5 (using a different remote cache) if not\r\n\r\n7. If the cache elected to retrieve the entire WAR, it (subject to\r\n   considerations like being behind a firewall) registers itself with\r\n   one of the site's LDAP servers as possessing the WAR and being\r\n   willing to serve it to other sites\r\n\r\n7a LDAP servers replicate this information among themselves\r\n\r\n8. Web cache runs the Java in the WAR to generate the dynamic web page\r\n   and returns the result to the client\r\n\r\nSeveral other options present themselves.  Perhaps the LDAP directory\r\nshould include entries for web caches willing to run the Java and\r\nserve the dynamic pages themselves, though this would be present a\r\nsecurity risk since those caches might be untrusted by either client\r\nor server.  Perhaps provision could be made for the server to issue\r\nX.509 certificates certifying certain web caches as trusted.  Perhaps\r\nthe user should be prompted before embarking on the potentially time\r\nconsuming process of retrieving and locally processing a WAR.\r\nFinally, the functionally of a \"locally trusted cache\" should\r\nultimately be rolled into the client itself, which should retrieve and\r\nverify the integrity of the WAR before running the Java itself.\r\n\r\nIn summary, I recommend the following steps:\r\n\r\n1. Recognize the importance of data-oriented design, as opposed to\r\n   connection-oriented design.  Break the dependence on special server\r\n   configurations and realize that the client has to do almost all the\r\n   work in a scalable, cached, redundant web architecture.\r\n\r\n2. Select standards for the network delivery of executable web\r\n   content, and for packaging the contents of a web server into a\r\n   single compressed archive.  Java\/WAR seems the most likely current\r\n   candidate.\r\n\r\n3. Develop an LDAP schema for registering WARs, and for searching\r\n   the registrations to find the WARs matching a particular URL.\r\n\r\n4. Extend the WAR specification to include root URL, Java classes for\r\n   determining lifespan of WAR, performing incremental updates, and\r\n   other identified needs.  Specify the security environment in which\r\n   these \"foreign\" WARs will operate.\r\n\r\n5. Extend Squid to support the algorithm outlined above.  Alternately,\r\n   extend Apache Tomcat to function as a web cache, with similar\r\n   features.\r\n\r\nThe caching scheme outlined above is far from perfect.  In my essay\r\n\"Data-oriented networking\" I discuss more long-term prospects.\r\nHowever, the current proposal has several key advantages: it can be\r\ndeploying using existing technology; it requires no client-side\r\nchanges or client-visible protocol updates; it allows web sites to\r\neasily opt in so long as one public set of LDAP servers and\/or trusted\r\ncaches are available; and it solves a pressing problem.  Ultimately,\r\nthe Internet is a work in progress, and its more technically savvy\r\nusers are probably ready for a serious attempt at a working caching\r\nscheme for dynamic content.\r\n\r\n\r\n\r\n\r\nREFERENCES\r\n\r\nData-oriented networking\r\n\r\n   \"Data-oriented networking\", Brent Baccala, Internet Draft\r\n      http:\/\/www.freesoft.org\/Essays\/data-networking\/\r\n\r\nDomain Name System (DNS)\r\n\r\n   Dozens of RFCs specify various aspects of DNS operation.  Only\r\n   those most pertinent to basic DNS operation, SRV records, and\r\n   KEY\/CERT records are listed here.\r\n\r\n   RFC 1034 - Domain Names - Concepts and Facilities\r\n\r\n   RFC 1035 - Domain Names - Implementation and Specification\r\n\r\n   RFC 1912 - Common DNS Operational and Configuration Errors\r\n\r\n   RFC 2535 - Domain Name System Security Extensions\r\n\r\n   RFC 2536 - DSA KEYs and SIGs in the Domain Name System\r\n\r\n   RFC 2538 - Storing Certificates in the Domain Name System\r\n\r\n   RFC 2782 - A DNS RR for specifying the location of services (DNS SRV)\r\n\r\n   RFC 3110 - RSA\/SHA-1 SIGs and RSA KEYs in the Domain Name System\r\n\r\n   Paul Vixie's Internet Software Consortium produces BIND, the most\r\n   widely used (and freely available) DNS server\r\n      http:\/\/www.isc.org\/\r\n\r\nLightweight Directory Access Protocol (LDAP)\r\n\r\n   RFC 2251 - LDAP v3 (protocol spec)\r\n\r\n   RFC 2252 - LDAP v3 Attribute Syntax Definitions (schema spec)\r\n\r\n   OpenLDAP is an actively developed (as of mid-2002) open source LDAP\r\n   server, and C-based client library.  Various client implementations\r\n   exist for other languages, such as Perl\r\n      http:\/\/www.openldap.org\/\r\n\r\nRsync\r\n\r\n   rsync is a program and protocol developed to incrementally update\r\n   files that have only been slightly modified, by first transferring\r\n   a set of MD5 digests that identify which parts of the file have\r\n   been modified and only transferring those parts\r\n      http:\/\/rsync.samba.org\/\r\n\r\nJava\r\n\r\n   Java Virtual Machine (JVM) specification\r\n      somewhere on http:\/\/java.sun.com\/\r\n\r\n   Bill Venner's excellent Under the Hood series for JavaWorld\r\n   is a better starting point than the spec for understanding JVM.\r\n   He also has written a book - Inside the Java Virtual Machine\r\n   (McGraw-Hill; ISBN 0-07-913248-0)\r\n      http:\/\/www.javaworld.com\/columns\/jw-hood-index.shtml\r\n\r\n   Java 2 language reference\r\n      somewhere on http:\/\/java.sun.com\/\r\n\r\n   Java languages page (other languages that compile to Java VM)\r\n      http:\/\/grunge.cs.tu-berlin.de\/~tolk\/vmlanguages.html\r\n\r\n   Criticism of Java\r\n      http:\/\/www.jwz.org\/doc\/java.html\r\n\r\nJava Servlets\/WARs\r\n\r\n   \"Tomcat is the servlet container that is used in the official\r\n    Reference Implementation for the Java Servlet and JavaServer Pages\r\n    technologies.\"\r\n      http:\/\/jakarta.apache.org\/tomcat\/\r\n\r\n   Java Servlets - server-side Java API (CGI-inspired; heavily\r\n   HTTP-based) The Java servlet specification includes a chapter\r\n   specifying the WAR (Web Application Archive) file format, an\r\n   extension of ZIP\/JAR\r\n      http:\/\/java.sun.com\/products\/servlet\/\r\n\r\nCaching\r\n\r\n   RFC 3040 - Internet Web Replication and Caching Taxonomy\r\n      broad overview of caching technology\r\n\r\n   RFC 2186 - Internet Cache Protocol (ICP), version 2\r\n\r\n   RFC 2187 - Application of ICP\r\n\r\n   Squid software\r\n      http:\/\/www.squid-cache.org\/\r\n\r\n   NLANR web caching project\r\n      http:\/\/www.ircache.net\/\r\n\r\n   Various collections of resources for web caching\r\n      http:\/\/www.web-cache.com\/\r\n      http:\/\/www.web-caching.com\/\r\n      http:\/\/www.caching.com\/\r\n\r\n   IETF Web Intermediaries working group (webi)\r\n      http:\/\/www.ietf.org\/html.charters\/OLD\/web-charter.html\r\n\r\n   IETF Web Replication and Caching working group (wrec)\r\n      http:\/\/www.wrec.org\/\r\n\r\n   RFC 3143 - Known HTTP Proxy\/Caching problems\r\n\r\n   Cache Array Routing Protocol (CARP) - used by Squid\r\n      http:\/\/www.microsoft.com\/Proxy\/Guide\/carpspec.asp\r\n      http:\/\/www.microsoft.com\/proxy\/documents\/CarpWP.exe\r\n\r\n   RFC 2756 - Hypertext Caching Protocol (HTCP) - use by Squid\r\n\r\nNapster and its variants\r\n\r\n   Napster, the original peer-to-peer file sharing service, has been\r\n   fraught with legal difficulties, having recently entered bankruptcy\r\n      http:\/\/www.napster.com\/\r\n\r\n   Napster's protocol lives on, even if the service is dead.  It's\r\n   basically a centralized directory with distributed data\r\n      http:\/\/opennap.sourceforge.net\/\r\n      http:\/\/opennap.sourceforge.net\/napster.txt\r\n\r\n   Gnutella has emerged as the leading post-Napster protocol,\r\n   employing both a distributed directory and distributed data\r\n      http:\/\/www.gnutella.com\/\r\n      http:\/\/www.gnutelladev.com\/\r\n      http:\/\/www.darkridge.com\/~jpr5\/doc\/gnutella.html\r\n\r\n   Several popular clients use the Gnutella network and protocol\r\n      http:\/\/www.morpheus-os.com\/\r\n      http:\/\/www.limewire.org\/\r\n      http:\/\/www.winmx.com\/\r\n\r\n   Other proprietary peer-to-peer systems\r\n      http:\/\/www.kazaa.com\/\r\n\r\n   Other free peer-to-peer systems\r\n      http:\/\/www.freenetproject.org\/\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Internet Engineering Task Force INTERNET-DRAFT Expires March 2003 Standardized caching of dynamic web content by Brent Baccala baccala@freesoft.org August, 2002 This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that … <\/p>\n
Continue reading “Standardized caching of dynamic web content”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"episode_type":"","audio_file":"","podmotor_file_id":"","podmotor_episode_id":"","cover_image":"","cover_image_id":"","duration":"","filesize":"","filesize_raw":"","date_recorded":"","explicit":"","block":"","footnotes":""},"categories":[3],"tags":[],"series":[],"class_list":["post-54","post","type-post","status-publish","format-standard","hentry","category-networking"],"episode_featured_image":false,"episode_player_image":"https:\/\/www.freesoft.org\/blogs\/soapbox\/wp-content\/uploads\/2021\/03\/brent-300x300-1.jpeg","download_link":"","player_link":"","audio_player":false,"episode_data":{"playerMode":"dark","subscribeUrls":{"apple_podcasts":{"key":"apple_podcasts","url":"","label":"Apple Podcasts","class":"apple_podcasts","icon":"apple-podcasts.png"},"google_podcasts":{"key":"google_podcasts","url":"","label":"Google Podcasts","class":"google_podcasts","icon":"google-podcasts.png"},"spotify":{"key":"spotify","url":"","label":"Spotify","class":"spotify","icon":"spotify.png"},"stitcher":{"key":"stitcher","url":"","label":"Stitcher","class":"stitcher","icon":"stitcher.png"}},"rssFeedUrl":"https:\/\/www.freesoft.org\/blogs\/soapbox\/feed\/podcast\/the-soapbox","embedCode":"
Standardized caching of dynamic web content<\/a><\/blockquote>