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

Re: [rfc] redirects with neon

From: Mark Benedetto King <bking_at_answerfriend.com>
Date: 2002-03-29 02:50:43 CET

On Thu, Mar 28, 2002 at 07:50:25PM -0500, Ben Collins wrote:
> On Thu, Mar 28, 2002 at 03:44:48PM -0800, Greg Stein wrote:
> >
> > Absolutely. Unlike CVS, it means that we can actually move a repository,
> > leave a little redirect on the server, and not worry about clients need to
> > rejigger everything they do.

+1

That will be nice.

> >
> > The tricky part will be telling the app "<that> is now located <here>" and
> > having it do something smart. Especially if <that> is a whole directory and
> > everything needs to get shifted recursively.
>
> One other place that Sander pointed out where this would be useful is to
> have master read/write repo's, with read-only slaves. Redirect all the
> write operations to the master server. Thing is, in this case it is a
> "standard" operation (much like what I am doing with the http and https
> redirect). Any ideas on how to handle this specially?
>

I don't think write operations should be redirected.

RFC 2616:

10.3.2

  [...]

   If the 301 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

Of course, neon already deviates (intentionally) from this behaviour, but
it does it only on "read-only" request types ("HEAD","GET", "PROPFIND",
and "OPTIONS").

If you implement the read-only slaves as write-through caches, you
shouldn't need to redirect the writes.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 29 02:52:42 2002

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