Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Wed, 25 Jun 2014 08:34:24 +0000 (UTC)
From: "Robert Newson (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12723512.1403653925024.43968.1403685264574@arcas>
In-Reply-To: <JIRA.12723512.1403653925024@arcas>
References: <JIRA.12723512.1403653925024@arcas>
Subject: [jira] [Commented] (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


    [ https://issues.apache.org/jira/browse/COUCHDB-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043194#comment-14043194 ] 

Robert Newson commented on COUCHDB-2260:
----------------------------------------

RFC 7234 governs how HTTP 1.1 should cache and states (at https://tools.ietf.org/html/rfc7234#section-4.2.4);

"A cache MUST NOT generate a stale response if it is prohibited by an
   explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
   cache directive, a "must-revalidate" cache-response-directive, or an
   applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
   see Section 5.2.2).'

If adding a max-age=0 would help in particular cases (e.g, Varnish) then I don't see an objection to adding it. I hope you can see that the way you have filed tickets has been counterproductive (filing duplicates, addressing multiple issues in one ticket, and stating that things are bugs when you don't know the background).

I would like to address the substantive issues across the tickets you have filed. As I see them, there are two;

1) Send "Vary: Accept" in order for caches to correctly serve the right content-type
2) Add max-age=0 to ensure caches revalidate with the origin as they should

Further, I think you want to allow additional caching, where contacting the origin server is omitted. That is tricky as noted elsewhere. We're a database and correctness trumps performance every time. There must be cases where we can allow that kind of caching without breaking things but it is far more nuanced than your currrent understanding, I believe.


> 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)