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