From user-return-14471-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Jan 12 02:30:01 2011 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 18928 invoked from network); 12 Jan 2011 02:30:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Jan 2011 02:30:01 -0000 Received: (qmail 31657 invoked by uid 500); 12 Jan 2011 02:29:59 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 31603 invoked by uid 500); 12 Jan 2011 02:29:59 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 31595 invoked by uid 99); 12 Jan 2011 02:29:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jan 2011 02:29:59 +0000 X-ASF-Spam-Status: No, hits=2.4 required=10.0 tests=HTML_FONT_FACE_BAD,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.82.54] (HELO mail-ww0-f54.google.com) (74.125.82.54) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jan 2011 02:29:51 +0000 Received: by wwb31 with SMTP id 31so114942wwb.23 for ; Tue, 11 Jan 2011 18:29:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.163.203 with SMTP id a53mr269649wel.104.1294799370272; Tue, 11 Jan 2011 18:29:30 -0800 (PST) Received: by 10.216.88.21 with HTTP; Tue, 11 Jan 2011 18:29:30 -0800 (PST) In-Reply-To: <6B61BC0F-E64A-4D13-BD63-1D9950C381F5@apache.org> References: <554B8167-9FA0-46D1-A016-E9A493A70A91@apache.org> <497EF9F2-8F4F-41A5-85EC-7684857868C1@apache.org> <6B61BC0F-E64A-4D13-BD63-1D9950C381F5@apache.org> Date: Tue, 11 Jan 2011 21:29:30 -0500 Message-ID: Subject: Re: multiple view requests From: Chad George To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016367fadcf853efd04999cf8c7 X-Virus-Checked: Checked by ClamAV on apache.org --0016367fadcf853efd04999cf8c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I guess my question about ETags was whether most browsers would even try to send the "If-None-Match: *ETag*" on a POST request? I don't see how it would know which previous request ETag to use since it can't just be based on URL. Seems like we might have to micro manage this header field to get caching to work. Maybe a more important question is how much real time is etag caching saving? Does it short circuit the request processing any or does the entire database still get hit and it just reduces the time over the wire. On Tue, Jan 11, 2011 at 8:12 PM, Adam Kocoloski wrote= : > On Jan 11, 2011, at 5:40 PM, Alexandru Popescu =E2=98=80 wrote: > > > On Tue, Jan 11, 2011 at 10:07 PM, Adam Kocoloski > wrote: > >> Hi Alex, I agree, it's awkward. Note that CouchDB already supports > POSTing to a view to select several individual keys. If I recall correct= ly > that decision came down to the fact that > >> > >> a) servers put limits on the length of a URL (in mochiweb at the time = it > was 8KB) > >> b) GET requests with bodies are not well-supported > >> > >> so if a user wanted to select hundreds of keys from a view a POST seem= ed > like the path of least resistance. This multi-query support wouldn't > introduce any new weirdness in that respect. I'm open to alternatives, > though I think the POST option would probably still go forward because it= 's > so similar to existing features. > > > > Adam, > > > > I do agree that all these limitations do exist in various > > environments, but I'd say what is important for this discussion is if > > they exist in the CouchDB environment. > > > > What I actually mean by this is: > > > > 1. will anyone try to submit an 8k long GET from a browser? I highly > > doubt that and I assume this scenario is most of the time happening > > with a programmed client > > Agreed, but I'm not sure how that's relevant. Programmatic access to the > DB is an important use case, and CouchDB will not serve GET requests long= er > than 8k in its current configuration. > > > 2. is there an HTTP spec restriction related to the length of URIs? As > > far as I know there isn't one. > > > > 3. is there an HTTP spec restriction related to GET body? As far as I > > know there isn't one here either. > > > > So, based on these I'd say that if CouchDB is able to handle long URIs > > GETs and/or support GET bodies problem is solved. > > > > :- alex > > > > PS: I'm "lying" a bit here because there's also the problem of proxies > > that we would need to look at :-). > > Right, I think the lack of proxy support is a big issue, especially for G= ET > bodies. The restriction on URI length is configurable in mochiweb, but I > suspect it would be unwise to crank it up as high as the limit on request > bodies. > > Let me clear - I'm not at all opposed to adding multi-query GET requests > (probably using GET bodies). I just think that we'll ending up providing= a > POST interface for the same practical reasons that we currently have > multi-key view POSTs. Best regards, > > Adam > > --0016367fadcf853efd04999cf8c7--