Re: [rfc] redirects with neon

On Thu, Mar 28, 2002 at 08:50:43PM -0500, Mark Benedetto King wrote:
> 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:
>...
> > > 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?

If they were temporary redirects, then we wouldn't be pushing URLs back to
the application.

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

Yah... good point on the redirect on writes. We probably don't want to allow
those.

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

RFC 2616 was too specific when it mentioned GET/HEAD. The *intent* (and
confirmed by Roy Fielding) is to allow automatic redirect for any idempotent
request method.

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

Yup. But recognize: if a read-only slave is simply a caching proxy, then the
writes will write-through anyways.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org