Using WebDAV in EFT

EFT supports a subset of the WebDAV, which is an extension to the HTTP/1.1 protocol that allows clients to perform remote Web content authoring operations. HTTP defines many headers that can be used in WebDAV requests and responses. WebDAV provides functionality to create, change, and move documents on a remote server (typically a web server or "web share"). This is useful, among other things, for authoring the documents that a web server serves, but can also be used for general web-based file storage that can be accessed from anywhere. Important features in WebDAV protocol include locking (overwrite prevention), properties (creation, removal, and querying of information about author, modified date, etc.), name space management (ability to copy and move Web pages within a server's namespace), and collections (creation, removal, and listing of resources). Refer to the HTTP Extensions for Web Distributed Authoring and Versioning standard for more information.

As of EFT v8.0.5, the MKCOL method is no longer supported "out of the box"; however, you can enable it in the admin-configuration.json file. A new advanced property has been added to the file, "tunnelNonHttpVerbs": false. If NOT present (default) or set to false, it means WTC will continue to use MKCOL, COPY, and so on; if present and set to true, WTC will use POST with X-HTTP-Method-Override header for tunneling non-standard HTTP verbs.

All methods\headers marked as supported below (MKCOL, GET for Collections, DELETE for Collections, PUT for Non-Collection Resources, MOVE + Destination header) are used by ClientFTP and Web Transfer Client. EFT's Advanced Workflow Engine (AWE) works with the WebDAV protocol in the Get Email Action, Send email Action, and Exchange Action.

The table below indicates which WebDAV extensions are supported by EFT. The numbers indicate the section of the standard. Descriptions, status codes, and examples from the standard appear after the table.

Method	EFT Support
9.1. PROPFIND Method	NOT supported
9.2. PROPPATCH Method	NOT supported
9.3. MKCOL Method	Supported
9.4. GET, HEAD for Collections	Supported
9.5. POST for Collections	NOT supported
9.6.1. DELETE for Collections	Supported
9.7.1. PUT for Non-Collection Resources	Supported
9.7.2. PUT for Collections	NOT supported
9.8. COPY Method	NOT supported
9.9.1. MOVE for Properties	NOT supported
9.9.2. MOVE for Collections	Supported
9.9.3. MOVE and the Overwrite Header	NOT supported
9.10. LOCK Method	NOT supported
9.11. UNLOCK Method	NOT supported
10. HTTP Headers for Distributed Authoring	NOT supported
10.1. DAV Header	NOT supported
10.2. Depth Header	NOT supported
10.3. Destination Header	Supported
10.4. If Header	NOT supported
10.5. Lock-Token Header	NOT supported
10.6. Overwrite Header	NOT supported
10.7. Timeout Request Header	NOT supported

Descriptions, Examples, and Error Codes

Method	Description, Examples, and Error Codes
9.3. MKCOL Method	MKCOL creates a new collection resource at the location specified by the Request-URI. Example: >>Request MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.example.com >>Response HTTP/1.1 201 Created Status and error codes: 201 (Created) - The collection was created. 403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of collections at the given location in its URL namespace, or 2) the parent collection of the Request-URI exists but cannot accept members.
9.4. GET, HEAD for Collections	The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET, when applied to a collection, may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence, it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection.
9.5. POST for Collections	Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus, the semantics of POST are unmodified when applied to a collection.
9.6.1. DELETE for Collections	DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URLs are to be deleted. >>Request DELETE /container/ HTTP/1.1 Host: www.example.com
9.7.1. PUT for Non-Collection Resources	A PUT performed on an existing resource replaces the GET response entity of the resource.
9.9.2. MOVE for Collections	A MOVE with "Depth: infinity" instructs that the collection identified by the Request-URI be moved to the address specified in the Destination header, and all resources identified by its internal member URLs are to be moved to locations relative to it, recursively through all levels of the collection hierarchy.
10.3. Destination Header	The Destination request header specifies the URI that identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters. Destination = "Destination" ":" Simple-ref