Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Mon, 1 Jul 2013 23:35:20 +0000 (UTC)
From: "Alexander Shorin (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12544090.1330132829258.195278.1372721720107@arcas>
In-Reply-To: <JIRA.12544090.1330132829258@arcas>
References: <JIRA.12544090.1330132829258@arcas>
Subject: [jira] [Updated] (COUCHDB-1422) Let _show/_list functions prevent
 caching
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/COUCHDB-1422?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Shorin updated COUCHDB-1422:
--------------------------------------

    Component/s: View Server Support
                 HTTP Interface
   =20
> Let _show/_list functions prevent caching
> -----------------------------------------
>
>                 Key: COUCHDB-1422
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1422
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface, View Server Support
>            Reporter: Nathan Vander Wilt
>            Assignee: Robert Newson
>            Priority: Minor
>
> While CouchDB's automatic ETag handling on Show/List functions is desirab=
le 95% of the time, I keep running into situations where I want to do somet=
hing handy in a documentless show function ("if all you have is a hammer...=
") but end up getting into trouble with cached responses.
> I think the most straightforward fix is to send along any ETag header in =
a viewserver response instead of the default. Currently, instead of *overri=
ding* the ETag header, the two headers are combined. This does "bust the ca=
che" in some browsers if the only attempt to revalidate the first one (whic=
h 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". Let=
ting a show/list function return a single garbage ETag would let it avoid h=
aving its result considered so strongly valid later.
> Consider my stupid simple little public IP address reflector (https://git=
hub.com/natevw/ipcalf/blob/master/shows/address.js) 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 req.info, random =
quote generator... None of these are practical if the response will quickly=
 end up locked by a cache =E2=80=94=C2=A0potentially in proxies well upstre=
am of the client =E2=80=94 based on an overly narrow definition (and IMO so=
metimes needless requirement) of idempotence.
> Letting the show function "bust the cache" by providing a response ETag w=
hich 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 a=
void 304-effects altogether:
>     function (doc, req) {
>         return {headers:{ETag:'"'+req.uuid+'"'}, body: "Your IP address i=
s: " + req.peer};
>     }
> [If such a function wanted to allow for some caching benefit, it could pr=
ovide an appropriate Expires header instead.]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira