9.2 Open Web Folder

Alice has previously configured a Web Folder, which in Windows serves as a mount point to a WebDAV repository. This Web Folder allows Alice to quickly navigate to the root of the repository at http://www.example.com/.

A Web Folder allows Windows Explorer and Office software to work with files stored on a remote WebDAV repository. It's similar to mounting the DAV repository as a drive, but it doesn't use a drive letter. Other applications cannot use the Web Folder, because it only works with Explorer and Office.

Windows Explorer can be used to view the contents of a Web Folder and do common file management operations (move, copy, rename, delete). In addition, Office software can be used to open files from and save them to the repository: The Open and Save dialogs in Office applications show My Network Places, where the user can select a Web Folder and then select files or directories inside the WebDAV repository. This chapter includes both Explorer and Office operations using Web Folders.

The process of opening a Web Folder and navigating through a few directories takes five PROPFIND requests (see Figure 9-2).

Figure 9-2. Summary of opening a Web Folder.

graphics/09fig02.gif

Not all of these requests are necessary for a client that caches a little more information. For example, the client could cache the Basic authorization challenge information from a previous connection, skip the Depth 0 request entirely, and shave two roundtrips off this process.

Web Folders does not use OPTIONS to find out what features the server supports. Perhaps Web Folders instead uses the PROPFIND response to see whether the server supports the supportedlock and lockdiscovery properties to confirm that the server supports locking.

9.2.1 Unauthenticated Request

Alice first opens the Windows Explorer tool and then opens the Web Folder that points to the WebDAV repository on www.example.com. This action triggers Web Folders to send a PROPFIND request to the server to get the properties of the repository's root collection. However, Web Folders doesn't immediately attempt to log Alice in. Since Alice's folder is not publicly readable, the server returns a 401 Unauthorized response.

The PROPFIND request from Web Folders is a depth 0 request because initially Web Folders is only interested in the collection properties. The request has no body, which makes it equivalent to an allprop request. The request has a Content-Type header even though there is no body this is a client software bug. The request contains a nonstandard Microsoft header, the Translate header, to indicate that Web Folders is an authoring client, as opposed to a read-only browser. These quirks are explained in more detail after the request listing (see Listing 9-1).

Listing 9-1 PROPFIND request from Web Folders.
 PROPFIND / HTTP/1.1 Content-Language: en-us Accept-Language: en-us Content-Type: text/xml Translate: f Depth: 0 Content-Length: 0 User-Agent: Microsoft Data Access Internet Publishing Provider DAV 1.1 Host: www.example.com Connection: Keep-Alive graphics/enter.gif 

Notice that this request does not include a body. A PROPFIND request without a body is equivalent to an allprop request, a request for all the properties on the resource.

Interesting Standard Headers

In this example, the Content-Type, Depth, and Connection headers are worth discussing.

  • The Content-Type header is meaningless because the request doesn't have a body. To work around the client software bug, the server can simply ignore the header if there is no Content-Length header and no body arrives immediately.

  • The Depth header is 0, meaning that the client is only interested in the properties of the root collection.

  • The Connection header (see Section 3.5.1) means that the client is able to keep the TCP connection open if the server is also willing.

Nonstandard Translate Header

This Web Folders request, like many from Web Folders, includes the Translate header with a value of false. This is a nonstandard header invented by Microsoft (briefly introduced in Section 5.3.3). It is not part of the WebDAV standard and may be safely ignored by WebDAV servers except when the client is attempting to GET a dynamically generated Web page.

Originally, the Translate header (with a value of false) meant that the server should not translate the Web page if the Web page is dynamically generated; instead, the server should return the unprocessed source code at that location. However, the header is included on all Web Folders requests, including requests like this one, where the Web page is not being requested. Thus, the header means that the client is advertising that it is an authoring client, not a regular Web browser.

The server may make a number of different choices based on the presence of Translate: f. For example, it could calculate the size of the resource differently, depending on whether the client is an authoring client or a browsing client. The header may also be safely ignored in most cases.

9.2.2 Authentication Challenge

The response to the PROPFIND request is an error, indicating that authorization is required and that the client is unauthenticated (see Listing 9-2). The 401 Unauthorized response must contain the WWW-Authenticate header to show the client the authentication methods that are available. The response has a body, although bodies on error responses are optional.

Listing 9-2 401 Unauthorized response.
 HTTP/1.0 401 Unauthorized WWW-Authenticate: BASIC realm="www.example.com" WWW-Authenticate: Digest realm="www.example.com",    stale=false, nonce="ec2cc00f21f71acd35ab9be057970609",    qop="auth", algorithm="MD5" Cache-Control: no-cache Pragma: no-cache Date: Sat, Sun, 18 Nov 2001 22:23:32 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 187 Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 ) graphics/enter.gif <html><title>Error 401</title><body> Error: 401 <BR><H1>Forbidden</H1><BR>That action is not authorized. Please ensure that you are graphics/ccc.gif authenticated.<BR> <p><p></p></p> </body></html> 
Authentication Challenge

The WWW-Authenticate header values are the most important part of this response. These, along with the status code, indicate that the client must provide authentication information and how it may do so. WFS supports both standard authentication mechanisms, Basic and Digest [RFC2617]. This Digest authentication challenge was explained in Section 3.6.2.

Error Response Body

This response does have a body, even though error responses aren't required to have a body. The body includes HTML text in case the client is interested in displaying the body some Web browsers do. However, in this case, Web Folders does not display the body. Instead, Web Folders understands the 401 Unauthorized response status code and prompts Alice for her username and password. When these are entered, the PROPFIND request is repeated, with the Authorization header.

9.2.3 Authenticated PROPFIND

The next PROPFIND request authenticates the client as Alice on the given realm. It's identical to the previous PROPFIND request, with the addition of the Authorization header (see Listing 9-3).

Listing 9-3 PROPFIND request with authorization.
 PROPFIND / HTTP/1.1 [same headers as previous PROPFIND request] Authorization: Basic dGVzdHVzZXI6dGVzdHVzZXI= graphics/enter.gif 

Web Folders chose to use Basic authentication, even though the server offered Digest, which is more secure. Clients ought to choose the more secure authentication scheme. It's possible that the Web Folders designers believed that the order in which the server returned the schemes indicated a preference for the first one, the Basic authentication scheme. However, that belief is not supported by the standard on HTTP authentication schemes.

9.2.4 Collection Properties Response

Now that the client is authenticated, the server can respond successfully. WFS keeps authenticated users logged in with session cookies, so it sends session cookies in the Set-Cookie header. A successful PROPFIND response is a 207 Multi-Status response, as described in Section 7.2.2. This particular response body contains some nonstandard data-typing attributes, which WebDAV does not require but that are necessary to interoperate with Web Folders (see Listing 9-4).

Listing 9-4 Successful response to PROPFIND.
 HTTP/1.0 207 Multi-Status Set-Cookie: XythosSessionID=2600-2141502937;    Expires=Tue, 31-May-2005 09:33:57 GMT; Path=/ Set-Cookie: XythosUser=alice@1;    Expires=Tue, 31-May-2005 09:33:57 GMT; Path=/ Content-Type: text/xml; charset=UTF-8 Date: Sun, 18 Nov 2001 22:23:32 GMT Content-Length: 928 Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 ) graphics/enter.gif <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"    xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">    <D:response>       <D:href>http://www.example.com/</D:href>       <D:propstat>          <D:prop>             <D:resourcetype><D:collection/></D:resourcetype>             <D:displayname><![CDATA[]]></D:displayname>             <D:creationdate b:dt="dateTime.tz"> graphics/ap03inl01.gif                1970-01-01T00:00:00Z</D:creationdate>             <D:lockdiscovery></D:lockdiscovery>             <D:supportedlock>                <D:lockentry>                   <D:lockscope><D:exclusive/></D:lockscope>                   <D:locktype><D:write/></D:locktype>                </D:lockentry>                <D:lockentry>                   <D:lockscope><D:shared/></D:lockscope>                   <D:locktype><D:write/></D:locktype>                </D:lockentry>             </D:supportedlock>             <D:getlastmodified b:dt="dateTime.rfc1123"> graphics/ap03inl01.gif                Sat, 17 Nov 2001 22:23:32 GMT</D:getlastmodified>          </D:prop>          <D:status>HTTP/1.1 200 OK</D:status>       </D:propstat>    </D:response> </D:multistatus> 
Allprop Response

This is the server's response to a request for all properties on the resource. However, it only includes dead properties and those defined in RFC2518, as many servers do (as discussed in Section 7.2.5). In this specific case, the collection does have additional live properties that aren't shown, such as those required to support access-control and versioning features. These are expensive to calculate and are unlikely to be useful to Web Folders.

Datatype Attribute and Namespace

The response includes an odd-looking namespace with an attribute named dt. The namespace was given the arbitrary prefix b: , just as the D: prefix is arbitrary for the DAV namespace.

The dt attribute indicates the datatype of the XML element, showing that the creationdate value is in the W3C and IETF recommended date and time format (dateTime.tz) [RFC3339]. The getlastmodified value is in a less portable date format (dateTime.rfc1123) defined in a much older specification [RFC1123].

An obsolete W3C working document defines the UUID namespace, the dt attribute name in that namespace, and two values for that attribute. Although that specification did not become a standard and is not a WebDAV requirement, Web Folders uses the datatype mechanism anyway. The server implementation includes the nonstandard datatype information in order to interoperate fully with Web Folders. Web Folders will not display dates in directory listings unless the datatype attributes are present.

Other clients must ignore attributes they don't understand, like the dt attribute, and in practice they do this perfectly well.

Cookies

Two cookies are given to the client in the response headers. Cookies are a common and standardized HTTP feature [RFC2965]. However, cookies are not required for WebDAV support, so servers that use cookies can't count on WebDAV clients to return them.

 
 Set-Cookie: XythosSessionID=2600-2141502937;     Expires=Tue, 31-May-2005 09:33:57 GMT; Path=/ Set-Cookie: XythosUser=alice@1;     Expires=Tue, 31-May-2005 09:33:57 GMT; Path=/ 

These cookies identify a session that the server uses to keep Alice logged in without having to authenticate Alice on every request. The server offers both Basic and Digest authentication to identify the user, but it switches to session cookies once the user is identified, because:

  • Session cookies are more secure than Basic authentication. When the client chooses to use Basic in every request, the chances of the user's ID and password getting discovered multiply. The password is valid until the user changes it, on every system that has the same password. If a hacker obtains a session cookie instead of a password, that cookie expires eventually, and the only compromised server is the one that gave out the cookie.

  • Session cookies are less secure than Digest but perform better. Digest provides some protection against replay attacks with nonces (Section 3.6.2), whereas session cookies are subject to replay attacks. However, Digest requires that the user's password be verified on receipt every time. If the user's password is stored on a directory server or password server rather than on the WebDAV server, the process of verifying that every time can be very slow. The session cookie allows the WebDAV server to verify the password once, and then it caches the session ID to be checked against future requests.

If a server decides to use session IDs, these should not be easily guessable and they should time out periodically to require a new Digest authentication.

Some WebDAV clients do not use cookies, instead sending the Authorization header on all requests. Support for cookies is entirely optional for both clients and servers.

9.2.5 Directory Contents Listing

In the next step, still in the process of opening the Web Folder, the Microsoft client sends another PROPFIND request. This is the third request shown in Figure 9-2, still part of opening the Web Folder. The Web Folders client still doesn't know the contents of the root folder, so it can't display the folder yet. This time, the client requests specific property names in the PROPFIND request (see Listing 9-5).

Listing 9-5 PROPFIND to get directory contents.
 PROPFIND / HTTP/1.1 Content-Language: en-us Accept-Language: en-us Content-Type: text/xml Translate: f Depth: 1 Content-Length: 489 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 Authorization: Basic YWxpY2U6Ym9yaXNhbmRkb3Jpcw== graphics/enter.gif <?xml version="1.0" encoding="UTF-8" ?> <a:propfind xmlns:a="DAV:" xmlns:b="urn:schemas-microsoft-com:datatypes">    <a:prop>       <a:name/> <a:parentname/> <a:href/> <a:ishidden/>       <a:isreadonly/> <a:getcontenttype/> <a:contentclass/>       <a:getcontentlanguage/> <a:creationdate/>       <a:lastaccessed/> <a:getlastmodified/>       <a:getcontentlength/> <a:iscollection/>       <a:isstructureddocument/> <a:defaultdocument/>       <a:displayname/> <a:isroot/>       <a:resourcetype/>    </a:prop> </a:propfind> 
Depth

In this request the Depth header has a value of 1. The client is now asking for the specified properties for all child resources of the root collection, as well as the root collection itself. It's unclear why Web Folders didn't just begin with this request and skip the Depth: 0 request entirely.

Cookie

The new request includes the cookies that the server provided. It also includes the Authorization header because Web Folders needs to stay logged in and has no way of knowing that the cookies provide a session ID that will keep the user logged in. The server could use either the session ID or the Authorization header to figure out who the user is, but WFS uses the session ID to improve performance. WFS continues to use the session ID and ignore the Authorization header until the session ID is missing or timed out.

Nonstandard Properties

Note that Web Folders is requesting a number of nonstandard properties. These are highlighted in Listing 9-5. Web Folders works even if it doesn't receive values for these properties, so the server can omit them and still interoperate with Web Folders.

graphics/excd_icon.jpg

The custom properties are in the DAV: namespace, even though they were defined by Microsoft and never standardized. Using the DAV: namespace for custom properties is strongly discouraged. The DAV: namespace is a URI scheme registered with the IANA (www.iana.org) for use by the IETF and the WebDAV Working Group. Use of the DAV: namespace without following the standards process can lead to real interoperability problems because clients and servers rely on particular semantics for properties. All custom properties should use a custom namespace, not the one reserved for the WebDAV standards.

9.2.6 Directory Contents Response

The response body is again a Multi-Status document, but this time it lists the direct children of the collection. The body includes one response element for each resource inside the root collection, plus a response element for the root collection itself. The framework is shown first because the entire body is quite long, and then we show the response element contents for just one item (see Listing 9-6).

Listing 9-6 Response to PROPFIND Depth: 1.
 HTTP/1.0 207 Multi-Status Content-Type: text/xml; charset=UTF-8 Date: Sun, 18 Nov 2001 22:23:32 GMT Content-Length: 3444 Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 ) graphics/enter.gif <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"    xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" >    <D:response>       <D:href>http://www.example.com/</D:href>       [omitted]    </D:response>    <D:response>       <D:href>http://www.example.com/hr/</D:href>       [omitted]    </D:response>    <D:response>       <D:href>http://www.example.com/users/</D:href>       [omitted]    </D:response> </D:multistatus> 

This is just the response framework; the property information for each resource has been omitted to keep the example brief. Note that the server no longer needs to send the client the Set-Cookie header; the client already has the cookies.

With this information, the client is able to show that the root collection of www.example .com contains two resources. It needs the property information for each of those resources to know how to display them. Listing 9-7 shows what one of the response elements looks like in detail with all the property information provided by the server.

Listing 9-7 Excerpt from PROPFIND response: Property values for /hr/ collection.
 <D:response>    <D:href>http://www.example.com/hr/</D:href>    <D:propstat>       <D:prop>          <D:creationdate b:dt="dateTime.tz"> graphics/ap03inl01.gif             2001-11-17T00:26:07Z</D:creationdate>          <D:getlastmodified b:dt="dateTime.rfc1123"> graphics/ap03inl01.gif             Sat, 17 Nov 2001 00:26:08 GMT</D:getlastmodified>          <D:displayname><![CDATA[hr]]></D:displayname>          <D:resourcetype><D:collection/></D:resourcetype>       </D:prop>       <D:status>HTTP/1.1 200 OK</D:status>    </D:propstat>    <D:propstat>       <D:prop>          <D:name/><D:parentname/><D:href/><D:ishidden/>          <D:isreadonly/><D:getcontenttype/><D:contentclass/>          <D:getcontentlanguage/><D:lastaccessed/>          <D:getcontentlength/><D:iscollection/>          <D:isstructureddocument/><D:defaultdocument/>          <D:isroot/>       </D:prop>       <D:status>HTTP/1.1 404 Not Found</D:status>    </D:propstat> </D:response> 

This response shows when the collection was created and last modified as well as its display name and type. Successful property values are returned with the 200 OK status code. All the other properties that Web Folders requested do not exist for that resource, so the server returns those property names associated with the 404 Not Found status code.

9.2.7 Navigation

After the last response, the client can finally display the contents of the Web folder, showing two collections. Alice opens the users collection and then opens the alice collection within that. Web Folders sends one more PROPFIND request for each folder that is opened (shown in Figure 9-2). These PROPFIND requests are identical to the example just shown, other than the Request-URI.



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