Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 10528 invoked from network); 14 May 2009 15:36:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 May 2009 15:36:18 -0000 Received: (qmail 8511 invoked by uid 500); 14 May 2009 15:36:17 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 8419 invoked by uid 500); 14 May 2009 15:36:17 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 8382 invoked by uid 99); 14 May 2009 15:36:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 May 2009 15:36:08 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 74.125.44.28 as permitted sender) Received: from [74.125.44.28] (HELO yx-out-2324.google.com) (74.125.44.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 May 2009 15:36:00 +0000 Received: by yx-out-2324.google.com with SMTP id 8so656623yxm.5 for ; Thu, 14 May 2009 08:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QgIkZH3C0LiVnJ6cL4wppCSPgDTXrZdKvcLBzKMP3iQ=; b=BGb9RNnUeF0SSpWGsUiRGBtrEd3+W6gm1kk4qxkW9zucf+ZsWnWBQAd/MjMAHn9CLe +g/SvtVny1qfl+s6FwB3o90FomWxz5uw604aKm1umBAoAeobvq++VVECDlgDitLrz5v3 lZcTiqGNekUWqtfhw3aE1EN1Py1uIIiB0o628= 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 :content-type:content-transfer-encoding; b=gI3A9UGIBgsazvwWK6DKRAQQ+bz5l4Ox5zkoDWl2QfQaBnJ3QvGTmbLBzMAOMBXi1R wRn+MAZsOoTaaBnKy+NGE+4/lGcpiM3x/7pRgrzFmDgfsftPErYcpCo1N7/Z8236Ix80 FkLXY080RxvkeRshZjZc72zcmg4kmkl6sI63E= MIME-Version: 1.0 Received: by 10.100.211.11 with SMTP id j11mr3277419ang.101.1242315339299; Thu, 14 May 2009 08:35:39 -0700 (PDT) In-Reply-To: <20090514072608.GA6258@uk.tiscali.com> References: <20090514072608.GA6258@uk.tiscali.com> Date: Thu, 14 May 2009 11:35:39 -0400 Message-ID: Subject: Re: Allow overridden request methods From: Paul Davis To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Thu, May 14, 2009 at 3:26 AM, Brian Candler wrote: > On Wed, May 13, 2009 at 06:58:47PM +0200, Jan Lehnardt wrote: >>> Sorry for responding to my original message instead of a reply in the >>> thread, but I seem to be having some issues with the mailing list. >>> Oliver, you are right, I could use a javascript wrapper for flash. The >>> problem with that is that it introduces a second dependency to >>> interact with the REST interface. >> >> It adds a second API and complexity to CouchDB to support >> non-standard clients. I.e: If you don't speak HTTP, you can't >> talk to CouchDB. > > I think you'll find this is extremely common; many clients especially don= 't > implement DELETE. > > The way Rails deals with it is to allow a form POST to have a _method fie= ld, > and if it's present, it takes precedence over the HTTP method. > > actionpack/lib/action_view/helpers/url_helper.rb: > =A0 =A0 =A0 =A0 =A0method_tag =3D tag('input', :type =3D> 'hidden', :name= =3D> '_method', :value =3D> method.to_s) > > Of course, CouchDB doesn't take a application/x-www-form-urlencoded, it > takes an application/json body. So I think the nearest equivalent would b= e > to allow a "_method" member in the JSON body and honour it for all POST > requests [with JSON bodies]. Conveniently, CouchDB has already reserved a= ll > top-level keys beginning with underscores for its own purposes. > > Regards, > > Brian. > Eww. I'm all for supporting clients that have a brain dead HTTP interface, but piggybacking protocol information into the payload seems like not a good idea. If we're going to allow method overrides I'd vote +10 internets for the header version. But until someone shows me something that can't be accomplished using the _bulk_docs API I'd be -0 on supporting the header even. Paul Davis