couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <>
Subject [jira] [Assigned] (COUCHDB-1422) Let _show/_list functions prevent caching
Date Thu, 27 Sep 2012 17:18:07 GMT


Robert Newson reassigned COUCHDB-1422:

    Assignee: Robert Newson
> Let _show/_list functions prevent caching
> -----------------------------------------
>                 Key: COUCHDB-1422
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>            Reporter: Nathan Vander Wilt
>            Assignee: Robert Newson
>            Priority: Minor
>             Fix For: 1.3
> While CouchDB's automatic ETag handling on Show/List functions is desirable 95% of the
time, I keep running into situations where I want to do something handy in a documentless
show function ("if all you have is a hammer...") but end up getting into trouble with cached
> I think the most straightforward fix is to send along any ETag header in a viewserver
response instead of the default. Currently, instead of *overriding* the ETag header, the two
headers are combined. This does "bust the cache" in some browsers if the only attempt to revalidate
the first one (which happens to be that of the show function), but Firefox at least sends
both back and CouchDB finds its match and responds with 304 "Not Modified". Letting a show/list
function return a single garbage ETag would let it avoid having its result considered so strongly
valid later.
> Consider my stupid simple little public IP address reflector (
or the following show:
>     function (doc, req) {
>         return "Now is " + Date() + " and here is a unique identifier " + req.uuid +
" which might have more entropy than " + Math.random();
>     }
> There are a lot of interesting/fun things that are well within JavaScript's reach in
a (practically) side-effect free formatting function: different stylesheet based on user agent,
SVG chart of DB stats in, random quote generator... None of these are practical if
the response will quickly end up locked by a cache — potentially in proxies well upstream
of the client — based on an overly narrow definition (and IMO sometimes needless requirement)
of idempotence.
> Letting the show function "bust the cache" by providing a response ETag which CouchDB
won't re-validate would be a simple way to avoid this. With my proposal above, my IP address
example would simply override the ETag and avoid 304-effects altogether:
>     function (doc, req) {
>         return {headers:{ETag:'"'+req.uuid+'"'}, body: "Your IP address is: " + req.peer};
>     }
> [If such a function wanted to allow for some caching benefit, it could provide an appropriate
Expires header instead.]

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message