9.4 Create a New File

Now that Alice has created a new collection, she wants to create a new Word file and save it in that collection. Since a Web Folder already exists pointing to the WebDAV repository, Word is capable of saving a file right to the repository.

Many requests are involved in creating a new file. Web Folders confirms that the Web Folder location is still reachable, and then the user navigates to the correct location, before the file can actually be saved. Most of the methods involved in this process are requests we've already seen in detail, so we'll simply list the first line for each request. New methods not yet seen in this chapter are more interesting and are shown in full.

From Word, Alice chooses File:Save As..., then chooses Network Places and selects the Web Folder for this repository. Now the GUI needs to display the contents of the directory and confirm the functionality the server supports. This is done with two requests:

 
 OPTIONS / HTTP/1.1 PROPFIND / HTTP/1.1 

The GUI displays the results of the PROPFIND, the two folders /hr/ and /users/, so that Alice can either decide to save here or drill down into a subdirectory. Alice wants to save the file in her new collection, so she navigates to its location. Each time Alice opens a folder, Word needs to display its contents, so another PROPFIND request is generated for each level.

 
 PROPFIND /users HTTP/1.1 PROPFIND /users/alice HTTP/1.1 PROPFIND /users/alice/work HTTP/1.1 

Once inside the right directory, Alice types in the name for the new document and presses Save. Word generates three requests to lock the file, save it, and confirm the results:

 
 LOCK /users/alice/work/ergo-accessories.doc HTTP/1.1 PUT /users/alice/work/ergo-accessories.doc HTTP/1.1 HEAD /users/alice/work/ergo-accessories.doc HTTP/1.1 

In summary, eight requests are made by the client to navigate and open a new file. Most of the requests are necessary, given Word's user interface and the directory structure in the scenario. The OPTIONS response could have been cached on the client machine for a short while, but it's a good idea to refresh that information if it's not recent (see Figure 9-4).

Figure 9-4. Summary of saving new file.

graphics/09fig04.gif

9.4.1 LOCK Creates New Resource

Web Folders uses LOCK to create the new resource that Word hasn't even begun to edit yet. Web Folders requests a very short-duration exclusive write lock (see Listing 9-11).

Listing 9-11 LOCK request to create new resource.
 LOCK /users/alice/work/ergo-accessories.doc HTTP/1.1 Accept-Language: en-ca, en-us;q=0.5 Content-Length: 159 Timeout: Second-120 Translate: f User-Agent: Microsoft Data Access Internet Publishing    Provider DAV 1.1 Host: www.example.com Connection: Keep-Alive Cookie: XythosSessionID=2600-2141502937; XythosUser=alice@1 graphics/enter.gif <?xml version="1.0" ?> <lockinfo xmlns="DAV:">    <locktype><write/></locktype>    <lockscope><exclusive/></lockscope>    <owner>alice</owner> </lockinfo> 
Owner

The owner field Web Folders provides isn't very informative alice is a Windows user ID, not the user ID provided to log in to the WebDAV server. If the user is logged in to a home computer, the Windows user ID might be meaningless to all other users. (Many users log in to their home computer as "administrator" or do not log in at all.) If the user is logged in to an intranet with a Windows user ID, then other users on the same network can figure out what user alice is, but users on other intranets or home users can't get anything meaningful out of the value. Client software should attempt to do a better job of providing useful lock owner information, including a full user name, the userid that was provided to log in to the WebDAV server, and the client software identification.

Missing Content-Type Header

This request shows that Microsoft clients do not always send the Content-Type header, even when the request has a body. A LOCK request is supposed to have a XML body, and the server can examine the first five non-whitespace characters of the body to confirm that it is XML.

Servers seem to support requests like this without the Content-Type header. There is a Content-Length header, so at least the server has some indication that it should expect a request body (as opposed to a new request). Still, this example is noncompliant and should not be emulated by other clients.

User-Agent

The User-Agent value is the same one used when requests are triggered by actions in Windows Explorer. That's because Office 2000 and Windows 2000 Explorer use the same underlying software to handle WebDAV requests. Office 2000 is closely linked into the Web Folders software it can only use Web Folders that have already been configured, and it can't directly access a new URL even if the URL, points to a WebDAV server.

Two-Minute Lock

Two minutes is a rather short lock duration. It requires the client software to send another LOCK request every two minutes, as long as the user is editing the file, to keep the lock alive. If a server does not want to handle LOCK requests this frequently, it can grant a longer duration. The longer duration will be honored by Web Folders it will not send a refresh LOCK request until the exact second the server's chosen time period expires.

9.4.2 Creation of Lock-Null Resource

The LOCK request was sent to a URL that was not previously associated with a resource, so WFS creates a lock-null resource and responds with a 201 Created status and the lock token (see Listing 9-12).

Listing 9-12 Response to creation of lock-null resource.
 HTTP/1.0 201 Created Lock-Token: <locktoken:vserver1-LockTokendocstore1:9100> Content-Type: text/xml; charset=UTF-8 Date: Sun, 18 Nov 2001 22:29:14 GMT Content-Length: 385 Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 ) graphics/enter.gif <?xml version="1.0" encoding="utf-8" ?> <D:prop xmlns:D="DAV:"> <D:lockdiscovery>    <D:activelock>    <D:locktype><D:write/></D:locktype>    <D:lockscope><D:exclusive/></D:lockscope>    <D:depth>0</D:depth>    <D:owner>alice</D:owner>    <D:timeout>Second-119</D:timeout>    <D:locktoken>    <D:href>locktoken:vserver1-LockTokendocstore1:9100</D:href>    </D:locktoken>    </D:activelock> </D:lockdiscovery> </D:prop> 
201 Created

The 201 Created status shows that not only was the lock request successful, but a new resource was created. If the server hadn't created a new resource, it would have used the status 200 OK.

Lock Token Twice

The lock token, which the client must use in subsequent requests, is provided in two locations, as the WebDAV specification requires. Some clients depend on the lock token being in the header; other clients depend on the lock token being in the body.

Timeout

The timeout is a little less than the client requested, because the lock response was generated a fraction of a second after the lock was created. The client must always check the timeout anyway in case the server granted either a shorter or longer timeout than was requested. Since the lock creation response may be delayed on the network, the client should include a grace period anyway.

9.4.3 First Upload Request

As soon as the resource is locked, Word sends a copy of the new file. There may not be anything in the file, but it's a good idea to upload a blank but valid Word document immediately anyway. Other clients may be able to browse Alice's collection and download the file as soon as it's created. Since the file has a Word .doc file name extension, some clients will attempt to open the document in Word. It's better for those clients to see an empty Word document than a Word error message saying that the document is null. Note that even an empty Word document is almost 20,000 bytes long (see Listing 9-13).

Listing 9-13 PUT request to create file over lock-null resource.
 PUT /users/alice/work/ergo-accessories.doc HTTP/1.1 Accept-Language: en-ca, en-us;q=0.5 If: (<locktoken:vserver1-LockTokendocstore1:9100>) Translate: f Content-Length: 19456 Host: www.example.com Connection: Keep-Alive Cookie: XythosSessionID=2600-2141502937; XythosUser=alice@1 graphics/enter.gif [body omitted] 

The PUT request saves the initial content of the file to the server. It includes the lock token, as it must, because the resource is locked.

Missing Content-Type

An important header is missing in this request. Web Folders does not tell the WebDAV server the MIME type of the request body (it should be application/msword). The server has no way of telling what MIME type to use for the getcontenttype property, so it must use the default MIME type (application/octet-stream).

9.4.4 Server Saves File

The server saves the exact request body as the resource body. It generates a unique ETag for the new resource body (see Listing 9-14).

Listing 9-14 Response to PUT request.
 HTTP/1.0 204 No Content Content-Length: 0 Cache-Control: no-cache Pragma: no-cache Date: Sun, 18 Nov 2001 22:29:15 GMT ETag: "9300-9800" Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 ) graphics/enter.gif 

The 204 No Content status code shows that the resource was not created (it was created when it was locked), but its body was updated successfully. It also shows that the resource was given the ETag 9300-9800. The client should save the value of the ETag and use it in future requests, to make sure that the resource never changes unexpectedly. However, Web Folders is not as careful about using ETags as it could be.

9.4.5 Confirm File Upload

The last client step in creating the file is to confirm the file was saved, using the HEAD request. This request may confirm that the name is identical to what the client expected and that the length is correct, or it may serve to get the exact last modified datestamp. It may be important to check the name, because although Web Folders does caseless comparison on resource names, WebDAV servers must treat URLs as case sensitive. This is yet another Web Folders bug (see Listing 9-15).

Listing 9-15 HEAD request to verify new resource.
 HEAD /users/alice/work/ergo-accessories.doc HTTP/1.1 If: (<locktoken:vserver1-LockTokendocstore1:9100>) [typical headers omitted] graphics/enter.gif 

Note that it's not necessary to include the lock token in the HEAD request. The lock token is only required on requests that modify the resource. It doesn't hurt to include it in every request to the locked resource, and it may even be useful because it lets the client confirm the lock is still there (see Listing 9-16).

Listing 9-16 HEAD response.
 HTTP/1.0 200 OK Content-Type: application/octet-stream Content-Length: 19456 Accept-Ranges: bytes Last-Modified: Sun, 18 Nov 2001 22:29:15 GMT ETag: "9300-9800" Cache-Control: private Date: Sun, 18 Nov 2001 22:29:16 GMT Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 ) graphics/enter.gif 

The HEAD response shows the resource type, content length, ETag (showing the resource hasn't been changed), and date last modified. It's just like the response to a GET request, except it doesn't contain the body.



WebDAV. Next Generation Collaborative Web Authoring
WebDAV. Next Generation Collaborative Web Authoring
ISBN: 130652083
EAN: N/A
Year: 2003
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net