Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Tue, 24 Jun 2014 23:53:25 +0000 (UTC)
From: "Kaj Nielsen (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12723512.1403653925024.41847.1403654005589@arcas>
In-Reply-To: <JIRA.12723512.1403653925024@arcas>
References: <JIRA.12723512.1403653925024@arcas>
Subject: [jira] [Created] (COUCHDB-2260) CouchDB 1.6.0 returns wrong
 Cache-Control header
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Kaj Nielsen created COUCHDB-2260:
------------------------------------

             Summary: CouchDB 1.6.0 returns wrong Cache-Control header
                 Key: COUCHDB-2260
                 URL: https://issues.apache.org/jira/browse/COUCHDB-2260
             Project: CouchDB
          Issue Type: Bug
      Security Level: public (Regular issues)
          Components: HTTP Interface
            Reporter: Kaj Nielsen


CouchDB returns "must-revalidate" in all responses.

This does not mean what you think it means.

Modern HTTP caches will happily return cached copies of "must-revalidate" items without consulting the backend server.

According to the RFC:
================================================
Section 14.9.4 of HTTP/1.1:

When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server

Section 14.8 of HTTP/1.1:

If the response includes the "must-revalidate" cache-control directive, the cache MAY use that response in replying to a subsequent request. But if the response is stale, all caches MUST first revalidate it with the origin server...
================================================

Meaning that the cache may serve the item without revalidation as long as the response is not stale yet.

When is the response stale?

Regarding staleness, see for example RFC5861:
==============================================
A response containing:

     Cache-Control: max-age=600, ...

   indicates that it is fresh for 600 seconds
==============================================

Meaning that the content goes stale after the max-age expires.

Since CouchDB does not set a max-age, the cache may assume that the content does not go stale, and thus that must-revalidate is irrelevant.

Which is exactly what Varnish does when you stick it in front of CouchDB.

Correct solution is to set either:
 * Cache-Control: max-age=0, must-revalidate

Or:
 * Cache-Control: no-cache

The latter meaning that the cache must also refresh on each request (but is free to use conditional GETs if it wishes) - see RFC.

See also:
https://stackoverflow.com/questions/7573466/is-cache-controlmust-revalidate-obliging-to-validate-all-requests-or-just-the


--
This message was sent by Atlassian JIRA
(v6.2#6252)