couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kaj Nielsen (JIRA)" <j...@apache.org>
Subject [jira] [Reopened] (COUCHDB-2259) CouchDB 1.6.0 returns wrong Vary
Date Tue, 24 Jun 2014 23:43:24 GMT

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

Kaj Nielsen reopened COUCHDB-2259:
----------------------------------

    Skill Level: Guru Level (Everyone buy this person a beer at the next conference!)

> it's important to revalidate with the host server (in case it's changed).

There is no "in case it's changed".

It never changes.

Please read the original post again.  You haven't understood it (yet).

When the HTTP request is for a particular revision, that revision is immutable and _never
changes_.

Don't know how I can make this clearer - please read the original post again.


> This is still caching, the body can be served from the cache if the host server returns
a 304 response.

You don't much about the performance of HTTP caches...

Try and ask on eg. the Varnish mailing list how well a cache performs, when it has to revalidate
every request with the backend.

(Seriously, please do...)

Hint: Not so fast.


> 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