Side effects when deleting files from the server

DELETE Method

Preliminaries

This note provides supplementary information about the server's implementation of the standard HTTP DELETE method and its side effects.

The 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.

Cached files

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 BLUEPHRASE 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 dynamic-cache directory.

Directories

When a 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.

Request/response handlers

The server's request/response cycle for DELETE requests is fulfilled using this sequence of handlers:

	Request Handler	Optional	Configurable
1	Server Name Indication	no	no
2	Hosts	no	yes
3	IP Access	yes	yes
4	Resource Masks	yes	yes
5	Raw Path	no	no
6	Cookies	no	no
7	Forbidden	yes	yes
8	Cross Origin	yes	yes
9	RBAC	yes	yes
10	Content Length	no	no
11	Content Decoding	no	no
12	WWW Form Data	no	no
13	Multipart Form Data	no	no
	Dynamic Handler	Optional	Configurable
14	Router	yes	yes
	Response Handler	Optional	Configurable
15	File Permissions	no	no
16	Content Length	no	no
17	Status Codes	no	yes

Information Headers

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-deleted for the requested file itself — /public-dir/flowers/helianthus/annuus.blue.
rw-request-dir-deleted for the requested file's parent directory — /public-dir/flowers/helianthus.
rw-blue-file-deleted for the dynamically compiled BLUEPHRASE output — /dynamic-cache/flowers/helianthus/annuus.html.
rw-blue-dep-deleted for the dynamically compiled BLUEPHRASE dependency map — /dynamic-cache/flowers/helianthus/annuus.dep.
rw-blue-res-deleted for the dynamically compiled BLUEPHRASE resource map — /dynamic-cache/flowers/helianthus/annuus.res.
rw-blue-lnk-deleted for the dynamically compiled BLUEPHRASE link map — /dynamic-cache/flowers/helianthus/annuus.lnk.
rw-blue-dir-deleted for the dynamically compiled parent directory — /dynamic-cache/flowers/helianthus.
rw-encoding-file-deleted for the compressed cache file — /encoding-cache/flowers/helianthus/annuus.html.
rw-encoding-dir-deleted for the compressed cache parent directory — /encoding-cache/flowers/helianthus.

Permissions

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.

Status codes

Successful responses are finalized by the dynamic module with any of these status codes:

204 "No Content" if the requested file is successfully deleted, irrespective of the success or failure of any cached files or subdirectories.
207 "Multi Status" with a payload that has individual status codes for each part of the multipart request.
303 "See Other" when the processing is successful and the browser should issue a follow-on GET request to the URI declared in the response's location header.
307 "Temporary Redirect" when the processing is successful and the browser should issue a follow-on PATCH request to the URI declared in the response's location header.
409 "Conflict" if the requested file is not deleted, irrespective of the success or failure of any cached files or subdirectories.

Content length

DELETE requests must contain a content-length header. If not present, the request will fail with a status code of 411 and an information header of rw-content-length-missing.

The maximum size of a file to be uploaded is limited by the server to the size configured in restrictions/content-length-limit. If the file is too large, the request will fail with a status code of 413 and an information header of rw-content-length-limit.

Content encoding

DELETE requests may be uploaded in compressed form if the request includes an acceptable content-encoding header with a value of 'br', 'gzip' or 'deflate'. The uploaded request body will be decompressed and made available to plugin work orders in uncompressed form.

The request will fail with status code 406 if the Content Encoding module is not enabled or if the encoding value is not acceptable. An rw-content-decoding information header is added to this type of unsuccessful response.

Reference

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 DELETE requests.

Cookbook

Example: Enabling WebDAV DELETE through RBAC

host {
    modules {
        web-dav on
        rbac    on
    }
    plugins {
        router {
            `/login-logout/*`  *methods=POST  *plugin='rwserve-rbac-auth'
        }
    }
    rbac {
        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
        resources {
            `/login-logout/*`     *methods=POST                *roles=anonymous
            `*`                   *methods=GET,HEAD            *roles=anonymous
            `*`                   *methods=PUT,DELETE          *roles=devops
        }
    }
}