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 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
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|
|12||WWW Form Data||no||no|
|13||Multipart Form Data||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 BLUEPHRASE output —
rw-blue-dep-deletedfor the dynamically compiled BLUEPHRASE dependency map —
rw-blue-res-deletedfor the dynamically compiled BLUEPHRASE resource map —
rw-blue-lnk-deletedfor the dynamically compiled BLUEPHRASE 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.
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
GETrequest to the URI declared in the response's
307"Temporary Redirect" when the processing is successful and the browser should issue a follow-on
PATCHrequest to the URI declared in the response's
409"Conflict" if the requested file is not deleted, irrespective of the success or failure of any cached files or subdirectories.
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
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
DELETE requests may be uploaded in compressed form if the request includes an acceptable
content-encoding header with a value of
'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.
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