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.
In 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 fro 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:
|
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 |