couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joan Touzet (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (COUCHDB-2261) CouchDB 1.6.0 returns wrong Cache-Control header
Date Wed, 25 Jun 2014 00:01:30 GMT

     [ https://issues.apache.org/jira/browse/COUCHDB-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Joan Touzet closed COUCHDB-2261.
--------------------------------

    Resolution: Duplicate

Duplicate of COUCHDB-2260

> CouchDB 1.6.0 returns wrong Cache-Control header
> ------------------------------------------------
>
>                 Key: COUCHDB-2261
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2261
>             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)

Mime
View raw message