[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r33398 - trunk/notes

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Thu, 2 Oct 2008 09:58:05 -0700

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

---------------------------------------------------------------------
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 18:58:20 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.