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
> I don't think write operations should be redirected.
> RFC 2616:
> 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
> 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
> 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.
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Mar 29 20:23:31 2002