Side effects when deleting files from the server
This note provides supplementary information about the server's implementation of the standard HTTP DELETE method and its side effects.
DELETE method is used by WebDAV software and interactive AJAX calls to request the server to remove a resource.
When used in an AJAX call, a software developer must write a custom module with a handler to carry out the request (presumably via some type of server database), and the webmaster must configure a dynamic route with
*methods=DELETE which references that module.
When used with WebDAV software, the server will follow the predefined steps below to delete the static resource from the document-root.
DELETE requests always attempt to delete any cached copies of the target file. If the file has ever been the subject of a
GET request that used compression, then the server will attempt to delete the cached copy in the
encoding-cache directory. If the file is a blue-phrase file and its source was compiled into an HTML file, then the server will attempt to delete both the cached copy and the associated linkmap file, located in the
DELETE request removes the last file in a directory, the server attempts to delete the directory itself. This includes the public directory, the encoding cache directory, and the dynamic cache directory.
The server's request/response cycle for
DELETE requests is fulfilled using this sequence of handlers:
|1||Server Name Indication||no||no|
Information headers are added to the response for each file and directory that is successfully deleted. For example, if a request to delete
/flowers/helianthus/annuus.blue is the only remaining file in its parent directory, a successful response would contain these extra headers:
rw-request-file-deletedfor the requested file itself —
rw-request-dir-deletedfor the requested file's parent directory —
rw-blue-file-deletedfor the dynamically compiled blue-phrase output —
rw-blue-dep-deletedfor the dynamically compiled blue-phrase dependency map —
rw-blue-res-deletedfor the dynamically compiled blue-phrase resource map —
rw-blue-lnk-deletedfor the dynamically compiled blue-phrase link map —
rw-blue-dir-deletedfor the dynamically compiled parent directory —
rw-encoding-file-deletedfor the compressed cache file —
rw-encoding-dir-deletedfor the compressed cache parent directory —
The RBAC module is used to grant or deny permission to DELETE static files. If the RBAC module is not on, the request will fail.
The server's file system must grant the server's process write access to the area within the public directory which is the target of the request. The request will fail with status code
409 and an information header of
rw-request-file-not-deleted if adequate permissions aren't assigned.
If the requested file is successfully deleted, the status code is
204, irrespective of the success or failure of any cached files or subdirectories.
If the requested file is not deleted, the status code is
409, irrespective of the success or failure of any cached files or subdirectories.
For reference purposes, refer to IETF RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content section 4.3.5 for the basic protocol expected of HTTP
Example: Enabling WebDAV DELETE through RBAC
`/login-logout/*` *methods=POST *plugin='rwserve-rbac-auth'
roles `/etc/rwserve/roles` // the file created by the 'addrole' CLI utility
cipher-secret C#9fB$2gD@5zR*7e // secret used to encrypt the 'rw-roles' cookie
max-idle 1800 // number of seconds of inactivity before credentials expire
`/login-logout/*` *methods=POST *roles=anonymous
`*` *methods=GET,HEAD *roles=anonymous
`*` *methods=PUT,DELETE *roles=devops