couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: [Proposal] Change etag calculation
Date Tue, 12 Apr 2016 10:23:23 GMT
The etag would be derived from the response body not doc.body (as the patch shows, it was parts
of doc.revs and doc.body). It must include _rev for cache correctness. It doesn't need _id
as caching is per resource. It wouldn't be wrong to include it either, though. 

Sending correct etags in all cases is not controversial. The question is whether it's worth
the effort. Fixing etags for _local docs I consider essential now that user agents with caching
are performing replication tasks / reading and writing checkpoints. 

The current etag scheme for regular docs is not broken except in the corner case of user supplied
_rev. It's reasonable to fix that as long as we don't incur a huge cost but I'm happy with
the new status quo with garrens patch. 

> On 11 Apr 2016, at 17:11, Adam Kocoloski <> wrote:
> Cool. I’m a little confused about the MD5 for regular docs discussion. What’s the
driving force behind switching away from revisions as ETags. Is it
> 1) Users can break this by setting their own revisions
> 2) Documents with identical bodies but different revisions should be cacheable
> In case #1 a user operating at this level potentially breaks quite a bit more than the
caching mechanism, doesn’t she? I’d need to think through the full ramifications but I’d
love to see investment in the standardization of the revision generation algorithm as we discussed
in a recent thread, and then maybe be a bit more strict around the revision IDs that we accept
with new_edits=false.
> Case #2 also feels broken to me, we probably can’t be returning documents from a cache
with the wrong revision ID.
> Sorry if I’m missing the crux of the argument here.
> Adam
>> On Apr 11, 2016, at 10:43 AM, Garren Smith <> wrote:
>> Thanks for the feedback. For now I will proceed with getting the _local
>> fixes then. Then we can look at a performant way of doing the md5 for
>> regular docs.
>> Cheers
>> Garren
>>> On Sat, Apr 9, 2016 at 10:18 AM, Robert Newson <> wrote:
>>> The original patch from garren calculated the md5(body) at query time.
>>> This was fine for just local docs since fetching then is rare.
>>> I'm +1 on the proposal and agree we need to precalculate the etag for
>>> regular docs.
>>>>> On 8 Apr 2016, at 19:01, Alexander Shorin <> wrote:
>>>>> On Fri, Apr 8, 2016 at 8:55 PM, Mutton, James <>
>>> wrote:
>>>>> Is the proposal to calculate and store the md5 as a meta field, or to
>>> calculate md5(_rev, body) at request time?  Doing this at request time
>>> would be very expensive for heavily loaded servers.
>>>> Good point and concern. This is not a new meta field, just a Etag
>>>> header value. And obliviously, there should be the way to not generate
>>>> Etag value if it eventually the same as the _rev field value (I think
>>>> it's good idea to let them share the same algo).  Technically, this
>>>> could be done by looking on what kind of edit happened: interactive or
>>>> not.
>>>> --
>>>> ,,,^..^,,,

View raw message