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:34:24 GMT


Robert Newson commented on COUCHDB-2260:

RFC 7234 governs how HTTP 1.1 should cache and states (at;

"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:
>             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