couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2260) CouchDB 1.6.0 returns wrong Cache-Control header
Date Wed, 25 Jun 2014 08:50:24 GMT


Robert Newson commented on COUCHDB-2260:

I suggest moving this to the couchdb developer mailing list, JIRA is not the place for a discussion
as broad as this.

> CouchDB 1.6.0 returns wrong Cache-Control header
> ------------------------------------------------
>                 Key: COUCHDB-2260
>                 URL:
>             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:

This message was sent by Atlassian JIRA

View raw message