Perhaps it's preferable to use If-None-Match against the etag (whether md5 or sha1) in order to allow the server to decline within the protocol;
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html "The meaning of "If-None-Match: *" is that the method MUST NOT be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see section 14.44) exists, and SHOULD be performed if the representation does not exist" That is, send; PUT /whatever If-None-Match: "sha1/fdwdfwedewfwefwefwefwef" and get either a 201 (Created) or a 304 (Not Modified). Both would count as success but the latter precludes sending the request body. Unless I've read the spec wrong, of course. B. On Wed, Aug 5, 2009 at 11:25 AM, Brian Candler<[email protected]> wrote: > On Tue, Aug 04, 2009 at 02:13:39PM +0100, Robert Newson wrote: >> Firstly, I'd suggest it's md5 as damien already added that with the >> deterministic revs patch. > > But if we use SHA1, then it works as a git repository too :-) > >> But, given that, we could make an attachment >> upload with a Content-MD5 header return a successful status code >> without transferring the request body. > > That would depend on the client providing an Expect: 100-continue header to > allow the server to gracefully decline the body, rather than drop the > connection on the floor. > > I guess if you're going to do bypass content uploading, Content-MD5 is the > only possible header to use (Etag is a response header only AFAICS). But it > could just be done on a URL parameter, e.g. > > PUT /mydb/mydoc/attach1?sha1=da39a3ee5e6b4b0d3255bfef95601890afd80709 > > Regards, > > Brian. >
