Yaron.Redirect.NoWebDAV#2

The second related design issue facing the group is what method to use in
creating a redirect resource. It is a peculiarity of the human mind that it
constantly strives for unification. The manifestation of this odd habit in
the world of protocols is the constant desire to use only one method for
everything. In this case, the MKRESOURCE method. I believe that the
introduction of this method is directly contrary to the interests of the
majority of the WebDAV community. The basis for this assertion is that the
MKRESOURCE method, by its very design, forces an unnecessary unification of
functionality that inhibits the ability to extend functionality on an ad-hoc
basis. One of the great powers of HTTP is that its modular design allowed
for wide spread experimentation with new methods, headers, etc. on existing
platforms without having to change the code of the underlying server. This
is why we see such widespread support for mechanisms such as
ISAPI/NSAPI/Module extensions that allow new methods to be added to existing
servers.
The MKRESOURCE method is completely contrary to this trend. In fact, it
hinders experiment.
The MKRESOURCE method hinders experiment because a user of a server who
wishes to add support for the creation of a new resource type can't simply
throw in another Apache module and allow it to provide the code for the new
resource type. They have to find the code used for MKRESOURCE and change it
to support the new resource type. This means that whomever owns the code for
that module has complete control over what new types of resources can be
added to the server. This seems an unnecessary restriction.
As such I move that whatever method name is chosen for creating a redirect
resource it MUST be unique to the creation of redirect resources.