couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2259) CouchDB 1.6.0 returns wrong Vary
Date Wed, 25 Jun 2014 08:22:25 GMT

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

Robert Newson commented on COUCHDB-2259:
----------------------------------------


It is true that a given revision of a document does not change but the GET request might change
from a 200 response to a 404 response, which is why caches must revalidate with the origin
server.

Be assured that CouchDB developers are very familiar with the HTTP 1.1 specification and the
caching model in particular. We have deliberately chosen the current behavior to ensure that
correctly written HTTP caches are caching correctly. That performance suffers because of this
header is also a conscious choice, and one we are fully aware of. Cache hits for document
lookups are not very useful, where this matters more is attachments (if they're large) and
view queries (we skip the computation entirely if the view has not changed since you queried).

Finally, please stop filing duplicates of your issues. If you continue to do so I will have
your account disabled.

> CouchDB 1.6.0 returns wrong Vary
> --------------------------------
>
>                 Key: COUCHDB-2259
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2259
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: HTTP Interface
>            Reporter: Kaj Nielsen
>
> CouchDB documents are immutable.  Even when deleted, a new revision is assigned to the
document (and the _deleted flag is set).
> As such, HTTP requests for specific document revisions, by use of the If-Match header,
are cacheable.
> HTTP requests with no revision numbers are not cacheable.
> Therefore, for If-Match requests, the correct caching headers are:
>  - Vary: If-Match
>  - no Cache-Control header (or a default value, eg. 24hrs)
> And for "non-revisioned" requests, the correct headers are:
>  - Vary: If-Match
>  - Cache-Control: must-revalidate
> However:
> > GET /db/doc HTTP/1.1
> > Host: localhost:5984
> > If-Match: 167-37f82fdbfdc49d38b1c66815deb1e338
> > 
> < HTTP/1.1 200 OK
> < Server: CouchDB/1.6.0 (Erlang OTP/R15B01)
> < ETag: "167-37f82fdbfdc49d38b1c66815deb1e338"
> < Date: Tue, 24 Jun 2014 22:34:20 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 649
> < Cache-Control: must-revalidate
> < 
> ...
> As seen above, even when requesting a very specific revision of a document, CouchDB still
requests revalidation with "must-revalidate".
> Thereby making modern HTTP caches unable to take advantage of caching the (potentially
large) body of HTTP transactions that are perfectly cacheable (because the request include
If-Match).
> Also, CouchDB incorrectly  does not discern the request from a non-revisioned request
with regards to the "must-revalidate" cache-control header.  "must-revalidate" should not
be set on responses where If-Match is present in the request.



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

Mime
View raw message