9.7 Copy to Publishing Directory

When Alice is finished editing the file in her own working directory, she decides to publish the file. First, she has to get a copy of the file to the place where she wants to publish it, /hr/ ergonomics/. Alice accomplishes this task using the Explorer and Web Folders to copy the file and paste it to the destination. She checks to make sure the file is successfully copied and that it is viewable in its new location, and then she deletes the original copy in her work folder. Alice could also have used a Web Folders move (which would issue a WebDAV MOVE request), but sometimes users explicitly copy files instead of moving them.

Web Folders issues many OPTIONS and PROPFIND requests while Alice navigates to select a source directory, select a destination directory for the copy, and return to the source directory to delete the original file. The copy and delete operations are of course performed with the COPY and DELETE methods.

9.7.1 COPY File to Publish Location

The COPY request simply names the source and destination URLs, much like the MOVE request. The response is 201 Created, which means that the COPY request caused a new resource to be created at the destination (see Listing 9-20).

Listing 9-20 COPY request and response.

 COPY /users/alice/work/ergo-accessories.doc HTTP/1.1 Destination:    http://www.example.com/hr/ergonomics/ergo-accessories.doc Overwrite: F [typical headers omitted]  HTTP/1.0 201 Created Content-Length: 0 Cache-Control: no-cache Pragma: no-cache Date: Fri, 30 Nov 2001 22:53:58 GMT Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 )  

The Overwrite header value of false means that the client doesn't expect there to be a resource at the destination URL to be overwritten.

It's a good idea to include the Overwrite header, even though it's not required. If the Overwrite header is not present, it defaults to a value of true. That would overwrite the resource at the destination, even if the client didn't believe that a resource existed there.

9.7.2 Delete Working Copy

The DELETE request shows yet another nonstandard Microsoft syntax, the Destroy header, along with all the typical headers. The response is a simple success (see Listing 9-21).

Listing 9-21 Web Folders DELETE request and response.

 DELETE /users/alice/work/ergo-accessories.doc HTTP/1.1 Destroy: NoUndelete Content-Length: 0 [typical headers omitted]  HTTP/1.0 204 No Content Content-Length: 0 Cache-Control: no-cache Pragma: no-cache Date: Fri, 30 Nov 2001 22:54:09 GMT Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 )  

Destroy Header

The "noundelete" value of the Destroy header specifies that the file should be destroyed when it is deleted. It may seem obvious that deleting a file should destroy it, but there are other options: It could be marked for deletion, hidden, or moved to a Recycle Bin or trash folder.

When WFS gets DELETE requests for ordinary resources, it automatically moves them to a trash folder to allow users to recover from mistakes. In this case, it moves the file to a directory called /users/alice/trash/. Alice can view this directory using Web Folders or any other WebDAV client. She can empty it by deleting the files in the trash folder. When files are deleted from trash folders in WFS, they are destroyed completely.

Since the Destroy header is not standardized anywhere and WFS doesn't recognize this header, WFS moves the file to the trash folder rather than follow the client instructions. The Destroy header shows how easy it is for nonstandard protocol extensions to make a protocol less interoperable. The client was asking for specific action, but the server could not know that because the client used a nonstandard header.