From f2bfce2f9a6a0befbe6fcc59c6fdec2de7c4ae60 Mon Sep 17 00:00:00 2001 From: des Date: Thu, 23 Feb 2006 14:32:11 +0000 Subject: [PATCH] Discuss expiry and cacheability. git-svn-id: svn+ssh://projects.linpro.no/svn/varnish/trunk@22 d4fa192b-c00b-0410-8231-f00ffab90ce4 --- .../en/varnish-specification/article.xml | 136 +++++++++++++----- 1 file changed, 103 insertions(+), 33 deletions(-) diff --git a/varnish-doc/en/varnish-specification/article.xml b/varnish-doc/en/varnish-specification/article.xml index 7cee30f5..067d9315 100644 --- a/varnish-doc/en/varnish-specification/article.xml +++ b/varnish-doc/en/varnish-specification/article.xml @@ -26,7 +26,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described - in IETF RFC 2119. + in . XXX at this time, the above is incorrect because we started out using MoSCoW prioritisation before realising it was @@ -175,7 +175,7 @@ Internal documentation The internal documentation consists of: - + Code comments. @@ -197,14 +197,14 @@ documentation either in the project Wiki or in DocBook XML format. - +
External documentation The external documentation consists of: - + Manual pages for all daemons and command-line tools. @@ -220,7 +220,7 @@ Sample configuration files. - +
@@ -249,7 +249,7 @@ requests from both IPv4 and IPv6 clients. Varnish must, in general terms, handle these requests in - conformance with IETF RFC 2616. + conformance with . Varnish may handle HTTP/0.9 requests in any way it sees fit, including but not limited to returning a 400 Bad Request @@ -258,19 +258,21 @@ Varnish must use HTTP/1.1 in its communications with the content servers. - Varnish may deviate from IETF RFC 2616 when this is - necessary for interoperability with non-conforming clients or - content servers. + Varnish may deviate from when + this is necessary for interoperability with non-conforming + clients or content servers. - Varnish may deviate from IETF RFC 2616 in cases where - doing so provides a considerable performance advantage without - causing significant harm to interoperability. Any such - deviation must be documented. + Varnish may deviate from in + cases where doing so provides a considerable performance + advantage without causing significant harm to + interoperability. Any such deviation must be + documented. In its communications with clients, Varnish must - interpret IETF RFC 2616 as if it were an origin server. In - its communications with content servers, Varnish must - interpret IETF RFC 2616 as if it were a cache. + interpret as if it were an origin + server. In its communications with content servers, Varnish + must interpret as if it were a + cache.
@@ -323,18 +325,81 @@
- Expiry + Cacheability - If a cached document has an expiry time associated with - it, and that time has not yet been reached, Varnish may serve - the document from cache without contacting the content - server. + A request which includes authentication headers must not + be served from cache. + + Varnish must interpret Cache-Control directives received + from content servers as follows: + + + + public: the document will be cached even if + authentication headers are present. + + + private: the document will not be cached, since + Varnish is a shared cache. + + + no-cache: the document will not be cached. + + + no-store: XXX + + + s-maxage: overrides max-age, since Varnish is a + shared cache. + + + max-age: overrides the Expires header. + + + min-fresh: ignored. + + + max-stale: ignored. + + + only-if-cached: ignored. + + + must-revalidate: as specified in §14.9.4. + + + proxy-revalidate: as must-revalidate. + + + no-transform: ignored. + + + + Varnish must ignore Cache-Control directives received + from clients.
- Non-cacheable content + Expiry - XXX + If a content server returns a document with a s-maxage + directive, Varnish will set the expiry time for that document + to the time of the request plus the number of seconds + specified by the directive. + + If a content server returns a document with no s-maxage + directive but a max-age directive, Varnish will set the expiry + time for that document to the time of the request plus the + number of seconds specified by the max-age directive. + + If a content server returns a document with no s-maxage + or max-age directive but an Expires header, Varnish must set + the expiry time for that document to the value specified by + the Expires header. + + When sending a document to a client, Varnish must set + the Expires header to the document's expiry time.
@@ -422,7 +487,7 @@ Varnish must provide the data necessary to compute lifetime totals and sliding averages for the following: - + Total size of documents served to clients @@ -481,13 +546,13 @@ XXX length of request queues - + In addition, Varnish must provide the data necessary to compute the average, median and distribution for the following: - + Size of documents served, per unique document @@ -501,7 +566,9 @@ Requests per client connection - Client request completion time + Client request completion time, broken down by + request type (HEAD / GET), cache status (HIT / MISS) and + outcome (200, 404...) Content server connection duration @@ -510,12 +577,14 @@ Requests per content server connection - Content server request completion time + Content server request completion time, broken down + by request type (HEAD / GET) and outcome (200, + 404...) XXX time spent in request queues - + @@ -529,7 +598,7 @@ The following monitoring operations must be supported: - + Cache status of individual documents @@ -547,11 +616,11 @@ XXX - + The following tuning operations must be supported: - + Forced invalidation of individual documents @@ -561,7 +630,7 @@ XXX - +
Clustering @@ -714,5 +783,6 @@ + -- 2.39.5