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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>>> >>>>> On Fri, Apr 8, 2016 at 8:55 PM, Mutton, James <[email protected]> >>> 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. >>>> >>>> -- >>>> ,,,^..^,,, >
