couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: multiple view requests
Date Wed, 12 Jan 2011 03:17:40 GMT
On Jan 11, 2011, at 9:29 PM, Chad George wrote:

> 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.

Good question, I wouldn't be surprised if the browser support for it sucks.

> 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.

For single-document requests it doesn't save much at all.  But for view requests on a fairly
static database the savings can be substantial.  The server still needs to check the root
state of the view in question, but that's relatively cheap.  It doesn't need to visit any
of the actual leaf nodes in the tree in order to return a 304.  Best,

Adam

> On Tue, Jan 11, 2011 at 8:12 PM, Adam Kocoloski <kocolosk@apache.org> wrote:
> 
>> On Jan 11, 2011, at 5:40 PM, Alexandru Popescu ☀ wrote:
>> 
>>> On Tue, Jan 11, 2011 at 10:07 PM, Adam Kocoloski <kocolosk@apache.org>
>> 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 correctly
>> 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 seemed
>> 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 longer
>> 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 GET
>> 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
>> 
>> 


Mime
View raw message