Yaron.Redirect.NoAutoUpdate

The Foobar corporation has released their new redirection enhanced WebDAV
server. The server can easily run on top of multiple volumes and map the
volumes into the same URI namespace. In order to enhance the value of its
server the Foobar corporation has put in a really cool feature. If a
redirection resource and its target are both on the same volume then anytime
the target is moved (within that volume) the redirection resource will have
its location header response automatically adjusted. This isn't quite bind.
First of all, their server can't do the redirection internally, it still
needs to return a 302. Also, if the target is moved to another volume then
the update doesn't work. But still, most people tend to keep their files
together on the same volume so this is a really cool feature.

Johnny then comes along to update his website. Because Delta-V doesn't exist
he has to version by hand. The way he does it is by having a single
redirection resource that points to his "tip" version directory. When
version six of the website was ready Johnny moved the "tip" directory to the
"five" directory and moved the "six" directory to the "tip" location. This
enabled Johnny to update his website using a RFC 2518 client. This was
useful because while Johnny had a redirect enabled client at home he often
had to work on the road from random machines which usually had a RFC 2518
client such as Web Folders but didn't necessarily have a redirection client.

However, unbeknownst to Johnny, he is using the Foobar corporation server
and his redirection resource along with all of his files are on the same
volume. So when Johnny moved the "tip" directory to the "five" directory the
Foobar server happily updated the target of the redirection resource to
point to "five". So when Johnny tested out his website he saw the old
content instead of the new content. Since Johnny's request was a GET there
wasn't any notice of the redirection or its destination so he couldn't even
see that he was being sent to "five". He just typed in the URL, was quietly
redirected and ended up in the wrong place. Even if he had seen the
redirection URL (it could be displayed at the bottom of the browser window
during the redirect) he still wouldn't understand how it had gotten set to
"five". I can already hear the support phones ringing.

The point of this example is to point out that many users will expect that
since redirection resources do not guarantee integrity they will come to
rely on the lack of integrity. They will depend on being able to change the
target in all sorts of ways without having to worry that the redirection
resource will see those changes. So if someone moves the target and then
moved something else to the same name, they will reasonably expect that the
redirection resource has not changed the URI it is redirecting to.

Therefore I move that text be added to the definition of redirection
resources specifying that the location can only be set and can only be
changed through explicit user action. This will guarantee
consistent/reliable behavior across all redirection resource
implementations.