couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad George <c...@mgproducts.com>
Subject Re: multiple view requests
Date Wed, 12 Jan 2011 02:29:30 GMT
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message