Whatever Happened to the Destroy Header and the UNDELETE method?

Very early on the WebDAV WG recognized that versioning introduced two types
of DELETE. The first type of versioning system delete is used to prevent any
further successors to a resource from being created. The second type of
versioning system delete, usually referred to as destroy, was a lot harsher,
it meant to obliterate the resource, recover all storage and remove all
traces that be the resource ever existed.

At the same time it was recognized that certain types of WebDAV users were
likely to have explicit requirements for how a resource was DELETE’d. For
example, a military customer was likely to require that a MILSPEC approved
deletion algorithm be used. A classic example of a MILSPEC approved deletion
algorithm is the one that involves overwriting the deleted file with a
series of 1’s, 0’s and a random stream of bits.

The WG looked to the HTTP/1.1 spec for guidance but the spec was vague as to
what the term “delete” in the DELETE method really meant. So the WG decided
that it needed to provide a mechanism to specify what a DELETE meant.

At the same time the WG also recognized that if something could be deleted
it could quite likely also be undeleted. So undelete functionality was
contemplated.

To make a long story shorter the destroy header was introduced for use with
the DELETE method. The destroy header was completely extensible able to use
both tokens and URIs so new forms of delete could be added.

WebDAV defined three values for the destroy header, undelete, noundelete and
destroy.

"Destroy: undelete" on a DELETE method requested that the resource be
deleted in such a way that the UNDELETE method could be used to retrieve it
later, assuming no further changes were made in the meantime.

"Destroy: noundelete" on a DELETE method requested that the resource be
deleted in such a way that a future UNDELETE would fail.

"Destroy: destroy" requested that all traces of the resource's existence be
obliterated. Obviously an UNDELETE was expected to fail.

A problem with the destroy header was that it was being used on a method
defined by HTTP/1.1 not WebDAV. As such we couldn't require that anyone who
understood DELETE had to honor the destroy header since existing systems
which supported DELETE would just ignore the destroy header. We could have
required that WebDAV compliant resources support destroy but this didn't
really accomplish much. Without transactioning there was no way to guarantee
that from the time you performed discovery to the time you executed the
DELETE request with the destroy header the resource didn't decide to stop
supporting WebDAV. Therefore the WG had to mandate the use of PEP, later
simplified into Mandatory, with the DELETE method if the destroy header was
used. PEP/Mandatory provided a simple mechanism which guaranteed that
existing servers would reject the DELETE method but PEP/Mandatory compliant
servers would not.

If memory serves the UNDELETE method never actually made it into a published
draft, even though the destroy header did. I suspect that the reason for
this is that UNDELETE failed the "There are two kinds of features, mandatory
and not in the spec." We couldn't realistically mandate support for UNDELETE
because many systems didn't have facilities for supporting it and no
interest in introducing them. In fact the definition of the "undelete" value
of the destroy header specified that servers were free to ignore the request
and delete the resource in a manner that did not permit for UNDELETE. In
addition there were a lot of arguments about what exactly UNDELETE meant,
what guarantees if any did one get about the state of a resource after an
UNDELETE? What if the resource had been recreated and deleted again? Did we
need to hand out state tokens in DELETE responses so people could be sure
they were UNDELETing to the right state? Doesn't the whole thing sound like
versioning?

All of the previous questions could have been answered but in the end I
think the final nail in UNDELETE's coffin was that one could build a very
useful authoring system without support for UNDELETE. This argued that
UNDELETE did not need to be in the base spec.

The nail in the Destroy header's coffin came when the WebDAV specification
split out the versioning functionality. Destroy was primarily introduced for
use with versioning, this is why the header was named "destroy" in the first
place. With versioning no longer in the spec and with UNDELETE having never
even been introduced into the spec it was clear that the destroy header was
no longer critical to the successful use of the base WebDAV spec. In
addition since destroy required the use of PEP/Mandatory anyway we could
always add the feature to a future spec with no issues of backwards
compatibility.

Received on Wednesday, 10 February 1999 02:25:19 UTC