Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of robert.newson@gmail.com
 designates 209.85.218.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=LLhayH3v5N9syRbcbznCIVATn3UpUgRQLtqCxnXKlpV4Z6hvUJoWVCHmZKQb61kB2m
         hCyXHBcLcEk2f4y4hM3wEfxpHi3dvhfbcCBFrx1giruOSS+5pBswYwugnH0Q4GbLKqdy
         QqeTon53RuKatgYt3Gv61M4gEaLNkCWquMmBo=
MIME-Version: 1.0
In-Reply-To: <20090805102511.GA9689@uk.tiscali.com>
References: <46aeb24f0908040613t7b0102a6q6ad869598e32464e@mail.gmail.com>
	 <20090805102511.GA9689@uk.tiscali.com>
Date: Wed, 5 Aug 2009 13:20:06 +0100
Message-ID: <46aeb24f0908050520k3aaaac18keb2f9056bd293604@mail.gmail.com>
Subject: Re: History Proposal
From: Robert Newson <robert.newson@gmail.com>
To: Brian Candler <B.Candler@pobox.com>
Cc: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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<B.Candler@pobox.com> 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 th=
e
> only possible header to use (Etag is a response header only AFAICS). But =
it
> could just be done on a URL parameter, e.g.
>
> =A0 PUT /mydb/mydoc/attach1?sha1=3Dda39a3ee5e6b4b0d3255bfef95601890afd807=
09
>
> Regards,
>
> Brian.
>