From owner-freebsd-chat Tue May 11 13:51:17 1999 Delivered-To: freebsd-chat@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 4902F15060 for ; Tue, 11 May 1999 13:51:08 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id NAA00249; Tue, 11 May 1999 13:51:02 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpd000150; Tue May 11 13:50:48 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id NAA19560; Tue, 11 May 1999 13:50:46 -0700 (MST) From: Terry Lambert Message-Id: <199905112050.NAA19560@usr04.primenet.com> Subject: Re: Europe says yes to spam To: davids@webmaster.com (David Schwartz) Date: Tue, 11 May 1999 20:50:44 +0000 (GMT) Cc: paul@originative.co.uk, mavery@mail.otherwhen.com, chat@FreeBSD.ORG In-Reply-To: <000501be9bc0$c0ab23e0$021d85d1@whenever.youwant.to> from "David Schwartz" at May 11, 99 08:12:58 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Properly designed caching schemes will cache only static content and not > dynamic content. This should make it easy for competent administrators to > save some of their own bandwidth and leave their revenue streams > undisrupted. Actually, this isn't true. You could design a cache control that used a context identifier that knew about the dynamic nature of the content, and based a cache preterbation based on this. Ontologically, you could look at this as similar to the use of directories as files for AppleDouble, and for other types of metadata encapsulation in filesystem layers. I have frequently considered, in my copius spare time (yeah, right) adding an RFC 2068 compliant cache extension into Apache and SQUID (and maybe Harvest), that did the following: Cache-Control: no-cache dynamic-content-id="Authentication: bob" Where "Authentication: bob" is the authentication header sent with the initial request. This would allow the cached content to be retrieved. You could also envision other information, based on proxy authentication, and so on, which would allow a shared cache server to act as an unshared cache server. The point is, dynamic content is cacheable, if not in a shared server, then in an unshared one. Since the ``dynamic-content-id'' header specifies a cache semantic, and since proxies will only deal with the values they understand, and since semantic override is left-to-right, this allows the extension to be harmless in the face of a caching proxy that doesn't recognize the preterbation algorithm. In addition, a cache server or proxy cache server could specify a value for ``dynamic-content-id'' that reference d a cookie value, instead. This would allow the use of a cookie as a preterbation for cache (and hash) lookup, allowing the possibility that "Bob's sport page" and "Terry's sport page" are the same, and shared between the users, even though the content is "personalized" (dynamic). FWIW, I believe something like this will be necessary, as more and more companies "improve" their sites with "dynamic content", and simultaneously suck the agregate banwidth down into the toilet. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message