Using WebDAV with EFT Server

Using WebDAV in EFT Server

EFT Server 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 HTTP Extensions for Web Distributed Authoring and Versioning for more information about the standard.

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 Server's Advanced Workflow Engine (AWE) works with the WebDAV protocol in the Get Email Action, Send E-mail Action, and Exchange Action.

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

Method	EFT Server 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

This online help file is for EFT Server version 6.3.x. For other versions of EFT Server, please refer to http://help.globalscape.com/help/index.html.

(If the Index and Contents are hidden, click Show Contents pane in the top left corner of this topic.)

If this help topic did not help you, search the Knowledgebase or pose your question in the GlobalSCAPE User Forum.

For the most up-to-date information, to view version history, updates, and activation instructions; or to download a PDF of this user guide, visit the Support Center at http://www.globalscape.com/support.

Leave compliments or complaints regarding the help in the User Forum. At a minimum, please provide the topic title and why you needed help.

For information about GlobalSCAPE, visit www.globalscape.com, subscribe to our Secure Info Exchange blog, or follow us on Twitter.

Last modified: 20-Dec-11 at 15:59:57