I'm not sure that the CouchRequest.Timeout property behaves as intended. It is only applied to the HttpWebRequest in one of the CouchRequest constructors, which means that setting it has no effect, as setting can only occur after the constructor has executed. It's also only applied in the cookie constructor and not the basic auth one.
An option would be to make it a fluent method like Put/Get/etc. That would ensure that it is applied regardless of the constructor used, and would be consistent with the other methods on this class. (And it could be an int rather than an int? in this case.)
The other issue, which led me to this, is that it is impossible for a LoveSeat library user to set the CouchRequest Timeout when using the CouchClient. I'd like to set a long timeout for some view reindexing requests and i think there is no way to get to the CouchRequest object to do this. I'm not sure of the best solution, otherwise I would have submitted some code to implement it. My only idea so far is to have a Timeout property on CouchBase (and hence on CouchDatabase), which would be passed through to the CouchRequest in CouchBase.GetRequest. A LoveSeat user who wanted to change the timeout would set it on the CouchDatabase object before making a call; it would then retain that value until reset. This is not ideal, but the alternative would seem to be adding it as an optional parameter on all the CouchDatabase calls, which feels like overkill.
I'd be happy to put together some code to implement whatever solution seems best, but if you have a view on what that solution should be.
SetTimeout on CouchDatabase sounds a good plan. I'd be inclined to put it on the CouchBase class though, as that's where it's needed, and CouchDatabase inherits from that, so it would save pushing the information down the inheritance hierarchy.
I hadn't thought about the exception behaviour. The current implementation will throw an HttpException("Request failed to receive a response") on timeouts, which is certainly true. I'm fairly neutral between that and letting the WebException propagate - the latter lets the user determine the status more easily, but means they have to check two different kinds of exception. On balance I think I come down slightly in favour of the current implementation, but don't feel strongly.