9.8 Publish Document
| Alice's department has a very simple publishing workflow process. Documents are saved somewhere within the /hr/ collection, where the content can be verified and links can be tested. Every night, a process copies files from the /hr/ collection to the regular corporate Web server. However, this process only copies files that have a special property set. This property is named publish, and its value can be either true or false. It's in the namespace http://www.example.com/namespace/, a well-chosen namespace name because it includes the domain name of the company that defined the custom property. This simple process allows files to be reviewed and tested in place before they are published. When a document is finally "ready for prime time," the publish property is created and set to true. Alice asks Bob to double-check the new document. To review the document, Bob makes sure he can download the file and view it properly using IE 5.0. When Bob approves the document, Alice will use PROPPATCH to set the publish property so that all employees can view the new file. 9.8.1 Browser Request for WebDAV ResourceBob uses IE 5.0 to open the link from Alice. IE 5.0 is fairly concise in GET requests. The request needs no authentication, because the file was placed in a publicly readable directory (see Listing 9-22). Listing 9-22 GET from Internet Explorer 5.0.GET /hr/ergonomics/ergo-accessories.doc HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Host: www.example.com Connection: Keep-Alive The Anonymous request contains no authorization header and no session cookie, so the request is anonymous. It succeeds because the file is publicly readable. The file was copied to a publicly readable collection, and according to this server's policy, the file was made publicly readable, too. That's not a standard requirement; it's how this particular server was configured to handle permissions. 9.8.2 Setting Publish PropertyThe new document is in place and readable, and Bob finds no errors, so it's ready to publish. Bob emails Alice to let her know it's ready. Alice must now edit the value of that property on the resource so that the nightly site copy process will pick it up. Alice can't use Web Folders to set the value, because Web Folders doesn't offer any functionality to view or change custom properties. Therefore, Alice uses a simple command-line tool called cadaver to set the property. There is more information on what cadaver can do in the next chapter. There are other options besides using cadaver to set properties. For example, the Xythos WebFile Client allows the user to set a custom property name and value (but does not allow the user to choose a namespace). Listing 9-23 shows the complete cadaver version 0.17.0 user interface interaction, as Alice sets one property value. The characters Alice typed are shown in bold, and the rest of the characters are generated by cadaver or the operating system. Listing 9-23 Command-line user interface for cadaver.$ cadaver dav:!> open http://www.example.com/hr/ergonomics/ Looking up hostname... Connecting to server... connected. Authentication required for www.example.com on server 'www.example.com': Username: alice Password: ???????? Connecting to server... connected. Connecting to server... connected. dav:/hr/ergonomics/> set namespace http://www.example.com/namespace/ dav:/hr/ergonomics/> propset ergo-accessories.doc publish true Setting property on 'ergo-accessories.doc': (reconnecting...done) succeeded. dav:/hr/ergonomics/> quit Connection to 'www.example.com' closed. $ This listing shows what the user does to set the property value, but what is cadaver doing "under the covers"? To open the connection, cadaver does an OPTIONS request, then a PROPFIND request to make sure that the resource opened is a collection. Then, when the user sets the property, cadaver sends a single PROPPATCH request. Unlike Web Folders, it matters to cadaver what features the server supports, and it makes no assumptions. That's why it issues the OPTIONS request (see Figure 9-7). Figure 9-7. Summary of setting a property with cadaver.
9.8.3 OPTIONSThe OPTIONS request is sent first without authentication. The server responds with a 401 Unauthorized, just like Listing 9-2. The response includes the following headers: WWW-Authenticate: BASIC realm="www.example.com" WWW-Authenticate: Digest realm="www.example.com",stale=false, nonce="79820df5e55635e3df79581c4f01e8f7", qop="auth", algorithm="MD5" Unlike Web Folders, cadaver chooses the more secure authentication algorithm, Digest authentication, and resends its OPTIONS request with the Authorization header (see Listing 9-24). Listing 9-24 OPTIONS request from cadaver.OPTIONS /hr/ergonomics/ HTTP/1.1 User-Agent: cadaver/0.17.0 neon/0.12.0-dev Keep-Alive: Connection: TE, Keep-Alive TE: trailers Content-Length: 0 Host: www.example.com Authorization: Digest username="alice", realm="www.example.com", uri="/hr/ergonomics/", nonce="79820df5e55635e3df79581c4f01e8f7", response="fa3c7169539554a6571613b87512c0f4", cnonce="RnJpLCAzMCBOb3YgMjAwMSAyMjowMzoyOCBHTVQ=", algorithm="MD5", nc=00000001, qop="auth" In the request cadaver sent, three headers and header values appear that we haven't seen before. Keep-AliveThe Keep-Alive header is now obsolete. It was defined in RFC2068 (HTTP/1.1 specification dated January 1997, replaced by RFC2616 in June 1999), but RFC2068 did not specify any values. That RFC says "The Keep-Alive header itself is optional, and is used only if a parameter is being sent. HTTP/1.1 does not define any parameters." Thus, cadaver should not have included the header at all. However, it does no harm in this case. Connection: TE, Keep-AliveThe string TE in the Connection header means that the cadaver client supports chunked transfer encodings. The string TE must appear in the Connection header whenever the TE header is present. Keep-Alive indicates that the server can keep the connection open. The Connection header is defined in HTTP/1.1 [RFC2616]. TE: TrailersThe string TE means Transfer-Encoding again, but now it's a header of its own. The value trailers means that the client can accept trailer fields with a chunked transfer-encoding response. Trailer fields allow the server to put the headers at the end of the response rather than the beginning. It can help server performance in some cases, but WFS ignores the header and sends a regular un-encoded response. The TE header is defined in HTTP/1.1 [RFC2616]. 9.8.4 OPTIONS ResponseThe server responds with its standard OPTIONS response for a collection. This response includes the basic WebDAV support header (DAV), as well as a nonstandard header that Microsoft clients look for (MS-Author-Via) and a header from the Internet Draft for WebDAV Searching (DASL) (see Listing 9-25). Listing 9-25 OPTIONS response for a collection.HTTP/1.0 200 OK Set-Cookie: [omitted] Content-Type: text/html DAV: 1,2, access-control, ticket MS-Author-Via: DAV Allow: OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK, DELETE DASL: <DAV:basicsearch> Accept-Ranges: bytes Xythos-WFS-Version: Xythos WebFile Server 3.2.0.0 Date: Fri, 30 Nov 2001 22:03:27 GMT Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 ) DAV HeaderThe DAV header shows that WFS ("Xythos WebFile Server 3.2.0.0") supports WebDAV level 1, level 2 (locking) as well as access-control and ticket. The access-control feature is nearly standardized by the WebDAV Working Group and discussed in Chapter 12, Multifile Versioning. The ticket string advertises a feature that was proposed in an expired Internet Draft. It's not a good idea to use a simple short string like ticket to advertise a feature, unless that short string is standardized through the IETF. Two servers could advertise support for a feature named ticket but not mean the same thing by that name, unless it's standardized. Although the ticket feature was proposed in an Internet Draft, drafts expire and later implementors may be ignorant of the proposal. WebDAV does not make any recommendations as to what to do in this situation, but common sense suggests using something more unique than a simple string, such as a string including a domain name. Defining a complete new header isn't typically recommended, since doing so has an even greater risk of colliding with other headers of the same name. DASL HeaderThe DASL header shows that Xythos WFS supports the Distributed Authoring Search and Location (DASL) syntax, which is the WebDAV search proposal currently going through the standards process. Cadaver can ignore all of this. MS-Author-Via HeaderWebDAV requires the MS-Author-Via header to understand that the server supports WebDAV [q304133]. The server puts this header in all OPTIONS responses rather than try to guess if the client is Web Folders or not. 9.8.5 Setting a PropertyWhen the user asks to set a property value on a resource, cadaver sends a single PROPPATCH request (see Listing 9-26). Listing 9-26 PROPPATCH request from cadaver.PROPPATCH /hr/ergonomics/ergo-accessories.doc HTTP/1.1 User-Agent: cadaver/0.17.0 neon/0.12.0-dev Keep-Alive: Connection: TE, Keep-Alive TE: trailers Content-Type: text/xml Content-Length: 191 Host: www.example.com Authorization: Digest username="alice", realm="www.example.com", uri="/hr/ergonomics/ergo-accessories.doc", nonce="79820df5e55635e3df79581c4f01e8f7", response="fa076245916613bb64d5b4c1dbaa2a6c", cnonce="RnJpLCAzMCBOb3YgMjAwMSAyMjowMzoyOCBHTVQ=", algorithm="MD5", nc=00000002, qop="auth" No CookiesNote that cadaver ignores the cookies sent in the OPTIONS response and instead sends the Digest Authorization header again. This is an excellent choice; Digest is much more secure than using cookies or Basic authentication, and it protects the user's password and identity more effectively. No PrefixesCadaver does an interesting trick with the namespaces in this request. The root element of the XML body contains a declaration of the DAV: namespace as default namespace. That means that all elements in the body without a prefix are in the DAV: namespace except for the publish element, where the default namespace is redefined as http://www.example.com/namespace/. Recall that namespace declarations apply to an XML scope, which includes anything contained within the element where the declaration is made. Since the publish element contains the www.example.com namespace declaration, that scope ends when the publish element ends. The default namespace reverts to being the DAV: namespace. Any compliant XML parser should handle this properly without intervention. Digest DetailsThis time, the Authorization header has a different value for the response and nc (nonce-count). Digest authentication is designed so that replay attacks aren't possible. Contrast that with Basic authentication, where replay attacks are done simply by copying the entire header value and using it over and over again to reauthenticate. The response value contains a digest of the request body, which means that it provides some protection from modification or corruption of the request body in transit. 9.8.6 PROPPATCH ResponseThe PROPPATCH response is a success, confirming that the property in the given namespace on the requested resource successfully had its value changed. The headers for this response are very similar to other responses, so only the body is shown in Listing 9-27. Listing 9-27 PROPPATCH response: 207 Multi-Status response body.<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:ns1200="http://www.example.com/namespace/"> <D:response> <D:href>http://www.example.com/hr/ergonomics/ergo- The server refers to the same example namespace but assigns it a prefix ns1200. The DAV: namespace is also given a prefix D: . Although the prefixes differ, the namespaces are completely consistent with the PROPPATCH request. |
HTTP/1.0 200 OK Content-Type: application/msword Accept-Ranges: bytes Last-Modified: Sun, 18 Nov 2001 22:29:16 GMT ETag: "9300-9801" Cache-Control: private Content-Length: 21504 Date: Fri, 30 Nov 2001 22:46:09 GMT Server: Tomcat Web Server/3.3 Final ( JSP 1.1; Servlet 2.2 ) 
EAN: N/A
Pages: 146