Nasty ETag bug in http-proxy

[nolanlawson]

This is a bug that took me a long time to track down, and I don't have a good solution, so I'm going to document it thoroughly.

The Testing successive new_edits to the same doc, different content can sometimes fail with a bizarre error like this:

The root problem is that one test creates a document with the name foo and the rev 1-x and the next test does the same thing, but with different fields in the document. The second test ends up getting the document from the first test rather than its own.

How could this be possible? The database is deleted between every test, so that's not it. It turns out it's a proxy issue. When I set a breakpoint, I get this (correct) document back from localhost:5984:

{"_id":"foo","_rev":"1-x","bar":"baz"}

Whereas I get this (incorrect) document back from localhost:2020:

{"_id":"foo","_rev":"1-x","bar":"huzzah"}

What's happening is that pouchdb-http-proxy is caching the GET requests based on the ETag. Since the ETag is the same for both documents (1-x), it returns the old data.

I dug into the guts of pouchdb-http-proxy, but it seems like this is the behavior of a Node core module (http). I don't think it's reasonable for me to open a bug on Node (since it's doing what it's supposed to do - ETag is being used correctly). However I think this highlights the many problems we have with the proxy, and shows why I'm so eager to get rid of it.

[daleharvey]

I filed a bug on couchdb instead (https://issues.apache.org/jira/browse/COUCHDB-2764) Etags are supposed to reflect the content that is being served, we shouldnt get different documents with the same etag. Im down for removing the proxy since it has shown to be buggy, but I dont think its at fault here.

Merged the fix in 7c16604

[nolanlawson]

Fair enough. I guess I assumed the ETag behavior from CouchDB was correct. (Makes sense to me that it would be the rev, anyway.)