On Thu, Oct 2, 2008 at 12:58 PM, Justin Erenkrantz
> On Thu, Oct 2, 2008 at 9:34 AM, Ben Collins-Sussman
> <sussman_at_red-bean.com> wrote:
>> Curious -- why do you prefer putting the "verbs" and parameters
>> directly into the path space, rather than having them as query
>> strings? I had chat about this topic with gstein in IRC, and he
>> seemed to prefer query-args.
>> Is there really any technical advantage to one style over another, or
>> is it just a bikeshed?
> There's a tiny amount of bikeshed as I think you can make both work,
> but I think it's better to avoid query strings as there are at least
> some costs involved in supporting them. But, to me, I think doing
> everything as query args makes the module a tiny bit more complex that
> I think we could avoid.
> Caching is also a factor here - as if we use query args, we have to
> explicitly override and specify which responses are cacheable; but
> some caches are a little stupid and don't consider query args as ever
> being a differentiator. Also, from a server admin perspective, if we
> are explicit about verbage in the URL path space, it makes it slightly
> simpler to configure balancing/proxying. For example, I'd like to
> simplify the pass-through logic for the write-through mirror to just
> look at the URL space - looking at the bodies of the request is lame.
> Ideally, if we stick everything into URL space as paths, you could
> configure the load-balancing/write-through entirely with a cluster of
> ProxyPass directives - ProxyPass won't look at query strings, IIRC.
Are there any specific caching proxies that are known to work with the
current ra_serf to speed-up things like repeated checkouts? I've
tried Squid, Apache 2.2 and Polipo. They all work with Neon, but when
I try to use Serf no requests work. I always get an error:
svn: Error running context: Address family not supported by protocol family
In servers I have:
http-proxy-host = 127.0.0.1
http-proxy-port = 8080
http-library = serf
I am guessing this has something to do with HTTP 1.1 ?
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-02 19:12:54 CEST