An interesting observation is that a 403 HTTP response, which a `forbidden`
could generate for individual docs will trigger a cookie refresh.
However replicator, in the normal case would write documents using a
`_bulk_docs` endpoint and the result of that is `201` even though some
documents in the batch failed with a `forbidden` error.
It is possible to trick the replicator to use single requests if attachments
are used. Indeed, I had waited till the after the session expired and added a
document with an attachment to the source:
```
curl -s -XPUT
adm:pass@localhost:15984/srcdb/1/att1?rev=1-66e95cbbe626e928747ecc225341b2d6 -H
'Content-Type: application/octet-stream' -T 1mb
{"ok":true,"id":"1","rev":"2-3dec55150ee06ac046419c71f00f5351"}
```
The script was running in the part with long sleep but as soon as the
attachment was added, the session was refreshed and the a few writes succeeded:
```
ocID: 4
Doc added to source, sleeping 7 seconds
Getting doc from target:
{"error":"not_found","reason":"missing"}
DocID: 5
Doc added to source, sleeping 7 seconds
Getting doc from target:
{"_id":"5","_rev":"1-66e95cbbe626e928747ecc225341b2d6","name":"adm"}
DocID: 6
Doc added to source, sleeping 7 seconds
Getting doc from target:
{"error":"not_found","reason":"missing"}
```
[ Full content available at: https://github.com/apache/couchdb/issues/1607 ]
This message was relayed via gitbox.apache.org for [email protected]
