|set|toc2=next=cols=2,80| |1WebDAV| |^ Web-based Distributed Authoring and (not) Versioning for the WASD package. |^ Effective WASD WebDAV file-space (without significant naming constraints) relies on being hosted on ODS-5 volumes. Behaviour hosting file-space on ODS-2 volumes is untested (though possible provided file naming is constrained to ODS-2 conventions). |^ WASD WebDAV methods and request headers, etc., are also propagated to the scripting environment and so functionality may be implemented using CGI, CGIplus or RTE based applications. |^ WASD proxy-serving supports WebDAV methods, header fields, etc. |^ Generally WebDAV clients are applications other than browsers and so response bodies with human-readable error explanations are unnecessary and consume bandwidth to no good purpose, and so not provided. |^ File-systems are notoriously latent components relative to the rest of the system (more so with VMS). Any operation to collections (directories) are not going to be atomic and for large collections requiring many sub-operations the potential for the process to be interrupted or otherwise disturbed are enormous. File-systems are not databases amenable to extensive ACID operations. |^ In addition each file under WebDAV management has the potential for an associated but independent metadata file. This of course means for every DAV-specific resource file activity there is at least a file-system action to check for a metadata file and for some actions such as COPY the potential for an associated but entirely independent file operation. |^ Of course WebDAV was not intended or designed as a general file-system protocol but one for distributed management of somewhat restricted collections of Web-related resources and so in context probably works well enough. |^ See sections below on file-system operation method restrictions. |note| |0Caution| If using WebDAV in any serious fashion the likes of |code| $ HTTPD/DO=RESTART=NOW |!code| |^ during server WebDav file-system modifications is a recipe for inconsistency and/or corruption! |!note| |2HTTP Methods Supported| |^ A list of WebDAV methods, what WASD does with them, and any limitations or restrictions. Some of these are familiar HTTP/1.|/n| methods and other are RFC 4981 specific. Some of the HTTP/1.|/n| methods are overloaded with additional or variant behaviours when used in a WebDAV context. Issues of atomicity with the manipulation of file-system trees containing numbers of individual files makes strict RFC 4918 compliance difficult. See "|...|Restrictions" below. |table| |~_ |: Method|: Description |~ |~#* |. COPY** |. Reproduces both single resources (files) and collections (directory trees). Will overwrite files (if specified by the request) but will respond 209 (Conflict) if it would overwrite a tree. |~ |. DELETE** |. deletes files and directory trees |~ |. GET |. just the vanilla HTTP/1.1 behaviour |~ |. HEAD |. ditto |~ |. LOCK** |. see WEBDAV LOCKING below |~ |. MKCOL** |. create a directory |~ |. MOVE** |. Moves (rename or copy) a file or a directory tree. Will 'overwrite' files (if specified by the request) but will respond 209 (Conflict) if it would overwrite a tree. |~ |. OPTIONS |. If WebDAV is enabled and available for the path this reports the WebDAV extension methods |~ |. PROPFIND** |. Retrieves the requested file characteristics, DAV lock status and 'dead' properties for individual files, a directory and its child files, or a directory tree. |~ |. PROPPATCH** |. set and remove 'dead' meta-data properties |~ |. PUT |. Against a WebDAV resource behaves a little differently to historical WASD implementation of PUT. |~ |. UNLOCK** |. see WebDAV locking below |~#^* |. |. **|/WebDAV RFC 4918 method|| |!table| |^ WASD Statistics Reports gather WebDAV related data. Where a method can be used both for vanilla HTTP/1.|/n| and WebDAV purposes it is counted in WebDAV statistics if the request header contains some other indication of a WebDAV activity. |3COPY Restrictions| |^ Does not comply with the overwrite:T directive for collections (does so for files). Will not preemptively delete the existing tree. It returns a 209 (Conflict) response instead. |^ COPY does not maintain collection consistent URL namespace if a member resource cannot be moved as required by RFC 4918. It should maintain the source subtree completely uncopied. Instead it is best-effort and continues copying resources until exhausted. This is consistent with file-system behaviour. The RFC 4918 requirement, while not impossible, is fraught with issues inside a file-system. |3DELETE Restrictions| |^ Deletion of collections is particularly fraught with issues for a file-system. In userland it is almost impossible to predetermine if an individual file in a directory tree is going to resist deletion (due to locking, protections, etc) and in kernel land it's probably no easier. It leaves the undeleted tree hierachy (resource ancestors) intact. This is RFC 4918 compliant however! |^ So, in the case of WASD WebDAV it's just best-effort and if something down the tree won't disappear, it just reports the failure in the 207 response and carries merrily on through the tree regardless. This IS acceptable WebDAV server behaviour! |3MOVE Restrictions| |^ Does not comply with the overwrite:T directive for collections (does so for files). Will not currently pre-emptively delete the existing tree. It returns a 209 (Conflict) response instead. |^ MOVE first attempts to rename the file or directory. This is reasonably efficient, especially for directory trees but obviously only suitable for a target on the same disk volume. If a rename failure is due to a different device it falls back to using a COPY then DELETE in two separate phases. Needless-to-say this is hardly atomic and can lead to inconsistencies between source and target. |^ MOVE does not maintain collection consistent URL namespace if a member resource cannot be moved as required by RFC 4918. It should maintain the source subtree unmoved. Instead it is best-effort and continues moving resources until exhausted. This is consistent with file-system behaviour. The RFC 4918 requirement, while not impossible, is fraught with issues inside a file-system. |3If: Restrictions| |^ The conditional "If:" request header field does not have full RFC 4918 support. It implements lock token and etag token processing with parenthetical OR and NOT processing. For unsupported features WATCH reports that the header was not understood and always returns an abort status. WebDAV "If:" processing is an extrodinarily complex kludge for on-the-fly decision making by the server and much of what I have read indicates most clients only ever use extremely simple conditions anyway. |2WebDAV Configuration| |^ WebDAV and its features are globally enabled and configured using directives contained in the WASD_CONFIG_GLOBAL configuration file. |table| |~_ |: Directive|: Description |~ |~#* |. [PutMaxKBytes] |. maximum size of a file (PUT and POST) |~ |. [WebDAV] |. This directive enables and disables WebDAV. |~ |. [WebDAVlocking] |. Enables and disables WebDAV locking. |~ |. [WebDAVlockTimeoutDefault] |. see |link|Locking Timeout| |~ |. [WebDAVlockTimeoutMax] |. see |link|Locking Timeout| |~ |. [WebDAVlockCollectionDepth] |. See |link|Locking Depth| |~ |. [WebDAVmetaDir] |. see |link|WebDAV Metadata| |~ |. [WebDAVquota] |. Enables and disables RFC 4331 functionality (disk quota reporting). |!table| |^ In addition these and other configurations are provided on a per-path basis using mapping rules. |3WebDAV Set Rules| |^ WASD request processing rules (see |link%|../config/##Request Processing Configuration++of++WASD Configuration||) may be used on a per-path basis to modify (some) global configuration settings and provide other WevDAV configuation. |table| |~_ |: Rule|: Description |~ |~#* |. ODS=NAME=|/8BIT\|UTF8\|DEFAULT| |. When a file is PUT using WebDAV (or upload), for non-7bit ASCII file names use native ODS-5 8bit syntax (default) or UTF-8 encoded character sequences (see |link|File Naming||) |~ |. PUT=MAX= \| * |. Maximum number of kilobytes file size, if "*" then effectively unlimited (per-path equivalent of the global directive [PutMaxKBytes]). |~ |. WEBDAV=[NO]HIDDEN |. list (default) or hide U*x |/hidden|| files (i.e. those with names beginning with period) |~ |. WEBDAV=[NO]LOCK |. allow/apply WebDAV locking to this path |~ |. WEBDAV=[NO]PROFILE |. WebDAV access according to SYSUAF profile |~ |. WEBDAV=[NO]PROP |. allow/apply WebDAV 'dead' property(ies) to this path |~ |. WEBDAV=[NO]PUT=LOCK |. a resource must be locked before a PUT is allowed |~ |. WEBDAV=[NO]READ |. WebDAV methods allowed read this tree |~ |. WEBDAV=[NO]SERVER |. WebDAV access as server account (best effort) |~ |. WEBDAV=[NO]WINPROP |. when NOWINPROP windows properties are ignored and emulated |~ |. WEBDAV=[NO]WRITE |. WebDAV methods allowed write to this path (implied read) |~ |. WEBDAV=LOCK=TIMEOUT=DEFAULT= |. hh:mm:ss |~ |. WEBDAV=LOCK=TIMEOUT=MAX= |. hh:mm:ss |~ |. WEBDAV=META=DIR= |. per-path equivalent of global [WevbDAVmetaDir] (see |link|WebDAV Metadata||) |!table| |^ An essential function of the path setting rules is for specifying which paths in server Web-space are allowed to be accessed using the WebDAV protocol and what sort of access (read, write, etc.) that path is allowed. |3File Naming| |^ By default files that are PUT via WebDAV (or upload) support the ISO Latin-1 character set. ASCII and non-7-bit file names use the native ODS-5 syntax. Where character sets other than ISO Latin-1, or where compatibility with other WebDAV implementations is desired (e.g. Apache), a path can be set to allow file names supplied using UTF-8 sequences. |^ For example, the English language word "na\ïve", having a diaeresis mark over the "i" character (indicating it is pronounced separately from the preceding vowel) is commonly respresented using the 8 bit character 0xEF, or as the two byte UTF-8 sequence 0xC3AF. This word if used as the file name with a type (extension) of ".TXT" by default would have the sequence of 8-bit characters |code| 0x6E 0x61 0xEF 0x76 0x65 0x2e 0x54 0x58 0x54 |!code| and if the path had been set |/ods=name=utf8| the sequence would be |code| 0x6E 0x61 0xC3 0xAF 0x76 0x65 0x2E 0x54 0x58 0x54 |!code| |^ "Index of" (directory) listings will honour a path set |/ods=name=utf8| and make the listing character set UTF-8 resulting in a browser correctly rendering the name (WebDAV listings are by definition UTF-8). |0File Name Ambiguity|| |^ While files and directories created via WebDAV will have a consistent naming schema applied those created by applications or manual operation on the VMS system can result in files that are not accessible with WebDAV. |^ For example the file name | |code| This^_is^_an^_EXAMPLE^.txt.;1 |!code| | would be presented to the client as | |code| This is an EXAMPLE.txt |!code| | which when provided in a URL as | |code| This%20is%20an%20EXAMPLE.txt |!code| | and translated from that URL into the file specification | |code| This^_is^_an^_EXAMPLE.txt;1 |!code| | of course will not be able to be accessed. |^ In addition, the two files | |code| This^_is^_an^_EXAMPLE.txt;1 This^_is^_an^_EXAMPLE^.txt.;1 |!code| | are distinct in the file-system, independently parsed from the directory structure, would be presented to the client as consecutive entries having the same name, with only the accessible file name actually available. | |code| This is an EXAMPLE.txt This is an EXAMPLE.txt |!code| |^ To avoid this situation a potentially ambiguous file name containing an escaped period and no type (extension) is ignored by directory listings and WebDAV property lists. When an ambiguous file name is detected it is reported in WATCH reports. |note| |0Avoid "Interesting" File Names| While most of these are corner-cases it is best to try and avoid |/interesting| file names that can challenge the rather convoluted VMS file-system environment. Inaccessible file names cannot of course be deleted or renamed via WebDAV and may result in directory (folder) deletion problems. These situations generally require manual intervention. |!note| |3File-system Access| |^ Is controlled using the mapping rules: |table| |~_ |: Rule|: Description |~ |~ |. WEBDAV=PROFILE |. access using request SYSUAF-authenticated security profile |~ |. WEBDAV=WRITE |. unconditional permission to read/write |~ |. WEBDAV=READ |. unconditional permission to read |~ |. WEBDAV=SERVER |. access using server account permissions |!table| |^ All access by WebDAV operations |*must have at least one set| against the path. If access is permitted by one of the above settings SYSPRV is enabled to allow that access using the server account. Therefore files and directories should have a SYSTEM:READ+WRITE+EXECUTE+DELETE protection or equivalent ACL permissions, or the access may fail totally or in some part of a supposedly atomic action. |^ These file-system access settings are applied in the order listed above. That is, if a path successively has one or more of the above settings applied during rule processing, when it comes to applying those access controls, SYSUAF profile is applied, then if no profile SETing access to read/write, then to read-only, then access via the server account. |^ In addition WebDAV access requires an authorisation rule against each path. |3File-system Authorisation| |^ All access by WebDAV operations |*must have one set| against the path. |^ All WebDAV access is a combination of WASD_CONFIG_MAP path setting and WASD_CONFIG_AUTH authorisation permissions. The least permissive of the two overrides the more. The combination of an authorisation rule and a path mapping rule mitigates the chance of opening unintended access into the file-system. |^ These is the test-bench environment used during development: |code| # WASD_CONFIG_MAP pass /dweb/* /dweb/* ods=5 webdav=write webdav=nowinprop # WASD_CONFIG_AUTH ["KLAATU"=WASD_VMS_RW=id] /dweb/* r+w |!code| |^ Note that WebDAV read/write access is a combination of the mapping and the authorisation rule (mapping WEBDAV=READ overrides authorisation read+write). Expect complications with Microsoft environments. |^ For test-benching you could avoid authorisation issues completely with: |code| # WASD_CONFIG_AUTH [world] /dweb/* r+w |!code| |3Concurrent Authorisation| |^ A common requirement is to provide concurrent general access and authorised WebDAV acccess to the same Web-space. This is accomplished by using two paths mapped into the same file-system space, the general access (non-authorised) path, and a WebDAV (authorised) path. The WebDAV client uses the authorised path and can then apply WebDAV methods to maintain the resources. |code| # WASD_CONFIG_MAP pass /web/* /web/* ods=5 pass /davweb/* /web/* ods=5 webdav=profile webdav=nowinprop # WASD_CONFIG_AUTH ["KLAATU"=WASD_VMS_RW=id] /davweb/* r+w |!code| |3Real-World Example| |^ The following configuration is taken from a site using WebDAV to allow users to manage their Web presence. The user mapping is a fairly standard configuration for VMS accounts (see |link%|../config/##Mapping User Directories (tilde character ("~"))++of++WASD Configuration||). User Web areas are in the [.WWW] subdirectory of the account home area. |code| # WASD_CONFIG_MAP # general and WebDAV access (order is important) user /~*/dav/* /*/www/* webdav=profile notepad=webdav user /~*/dav /*/www webdav=profile notepad=webdav if (pass:-1 && notepad:webdav) pass /~*/dav/* /d1/*/www/* if (pass:-1 && notepad:webdav) pass /~*/dav/* /d2/*/www/* user /~*/* /*/www/* dir=access if (pass:-1) pass /~*/* /d1/*/www/* if (pass:-1) pass /~*/* /d2/*/www/* |!code| |^ The four WebDAV access rules are located before the three general user access rules. The WebDAV rules are more specific. The first USER rule maps subdirectories - and the parent if a trailing slash is included. The second USER rule maps the parent directory for user agents that do not include trailing slash on their directory specifications (most it seems). |^ The second pair of rules |/reverse-maps| the VMS file-system specifications represented by the |/result| (right side) of the PASS rule into the path represented by the |/template| (left side) of the PASS rule. Mapping from file-specifications to paths is necessary because of the way the PROPFIND method searches the file-system and then reports its results to the client as URLs. |^ The use of the |/notepad| rule with a string of "webdav" (the actual string is not significant as long as it is unique within the rules) is used to conditionally process the reverse-mapping rules. They will be applied only to the requests originally mapped by the USER rules. The |/pass:-1| ensures the rules are only applied during reverse-mapping, not during request mapping. |^ The fifth rules maps general Web access to the user area. Remember, web access is to a user home subdirectory [.WWW]. |^ The sixth and seventh rules |/reverse-map| the VMS file-system specifications for the general USER rules for similar reasons to those described above. Why two? The user directories occur across two disk volumes and so each must be reverse-mapped. |code| # WASD_CONFIG_AUTH ["VMS username/password"=WASD_VMS_RW=id] /~*/dav/* read+write,profile,https: /~*/dav read+write,profile,https: |!code| |^ As noted above, WASD WebDAV requires both mapping and authorization rules (even for "world" - or non-authenticated - access). |^ In this case authorisation is only required for WebDAV access. There are two rules. The first authorises subdirectories and parent directories for agents that supply a trailing slash. The second for agents that do not provide a trailing slash. |0Why use |...|| |^ |...| two rules for each location? Why |code| user /~*/dav/* /*/www/* user /~*/dav /*/www |!code| rather than |code| user /~*/dav* /*/www* |!code| which would accomplish a |/similar| result? |^ For finer control. The first only matches requests with a path of "/~user/dav/subdir/" and "/~user/dav", whereas the latter matches "/~user/dav/subdir/" and "/~user/dav" and "/~user/david/" and "/~user/davros", etc. |2WebDAV Metadata| |^ Metadata is data (information) about data. WebDAV uses the concept of a resource |/property||. There are "live" properties and "dead" properties. Essentially the live properties are the dynamic characteristics of a file-system object represented by creation and modification date-times, object size, etc. WebDAV dead properties are those supplied by WebDAV clients as XML entities and stored associated with the particular WebDAV object, in WASD's case the file-system object (file or directory). WASD also uses the file metadata to store resource lock data (see |link|WebDAV Locking||). |0Metadata Files|| |^ WASD manages resource metadata using a separate file associated by name with the data file. This is done for reasons of programmatic simplicity and for the convenience of any command-line owner or sysadmin of the resources. No specialised tools are required. This metadata file can be stored in one of three locations. |number| |item| By default, WASD uses a metadata file in the same directory and the same name with "__wasdav" appended to the extension (type). All non-WebDAV WASD functionality ignores "*.*__wasdav;" files (e.g. directory listing, file GET). Of course other applications (e.g. directory listing) do not. |code| $ DIRECTORY/SIZE/DATE 01234*.* Directory WEB:[DAVweb] 01234^.56789.TXT;1 0.50KB 8-JUN-2009 23:07:19.26 01234^.56789.txt__wasdav;1 1KB 19-JUN-2009 03:20:34.50 0123456789.TXT;1 0.50KB 8-JUN-2009 23:06:59.16 0123456789.txt__wasdav;1 1KB 19-JUN-2009 03:19:14.67 |!code| |item| An alternate but still |/local| location, is in the WASD_CONFIG_GLOBAL [WebDAVmetadir] globally specified, or per-path |/SET /path webdav=meta=dir| directives. If specified as a subdirectory the metadata file is stored in a subdirectory of the data file directory using the same name with "__wasdav" appended to the extension (type). This is owned by the owner of the parent directory. The metadata directory does not appear in WASD WebDAV or file system listings. Choose something unique as the name cannot be used elsewhere in WebDAV space. |^ For example, with the global directive |code| # WASD_CONFIG_GLOBAL [WebDAVmetaDir] [.^.dav] |!code| specifying a subdirectory with a name containing a leading period (i.e. a U*x |/hidden| file), the data files |code| Directory WEB:[DAVweb] 01234^.56789.TXT;1 0.50KB 8-JUN-2009 23:07:19.26 0123456789.TXT;1 0.50KB 8-JUN-2009 23:06:59.16 |!code| would have the associated metadata files |code| Directory WEB:[DAVweb.^.dav] 01234^.56789.txt__wasdav;1 1KB 19-JUN-2009 03:20:34.50 0123456789.txt__wasdav;1 1KB 19-JUN-2009 03:20:24.77 |!code| |item| The final alternative uses the same directives as above but specifies a full directory path. In this case WebDAV metadata is stored completely separately from the data. This can be anywhere in available file-space. The web server account requires full access to this directory, with the simplest method of ensuring this to give ownership to the directory. This global location is only suitable for ODS-5 volumes. Sixteen hexadecimal named subdirectories are used to partition metadata files with file names generated using data file full name escaped using extended parse syntax. Using this approach a sysadmin can easily locate specific metadata files if required. |^ For example, with the global directive |code| # WASD_CONFIG_GLOBAL [WebDAVmetaDir] DKA0:[WASDAVMETA] |!code| the data files |code| Directory WEB:[DAVweb] 01234^.56789.TXT;1 0.50KB 8-JUN-2009 23:07:19.26 0123456789.TXT;1 0.50KB 8-JUN-2009 23:06:59.16 |!code| would have the associated metadata files |code| Directory DKA0:[WASDAVMETA.06] web^:^[davweb^]01234^.56789.txt__wasdav;1 1KB 19-JUN-2009 03:21:34.40 web^:^[davweb^]0123456789.txt__wasdav;1 1KB 19-JUN-2009 03:21:14.67 |!code| |!number| |0Directory Metadata| |^ The metadata file associated with a directory is stored in the same metadata location as files contained by that directory (not in the metadata location associated with the parent directory that contains the directory file). This metadata file is named ".DIR__wasdav" (i.e. no name, just an extension), with the following example illustrating how this would appear in each of the three metadata locations, for a subdirectory named "New Folder". |code| WEB:[DAVweb.New^_Folder].DIR__wasdav;1 WEB:[DAVweb.New^_Folder.^.dav].DIR__wasdav;1 DKA0:[WASDAVMETA.06]web^:^[davweb^.new^_folder^].dir__wasdav;1 |!code| |0Metadata XML| |^ All metadata is stored using XML. Multiple XML data can be contained in a single metadata file. Each can be individually manipulated by a WebDAV client. The property elements are stored as-supplied by the client. It is presumed that their XML well-formedness is guaranteed by the original request XML parsing. Metadata files have content similar to the following: |code| $ TYPE 0123456789.txt__wasdav;1 MGD three six nine |!code| |^ This metadata example contains four properties; an exclusive write lock owned by "MGD" and three set by a client in three different (contrived) namespaces. |note| |0Metadata should not be edited manually ...| |...| unless you really, really know what you're doing. WASD deletes meta-data files it does not understand or otherwise considers damaged (with some resultant loss of information). Of course you can, for example to remove a lock on a resource, but you run the (small) risk of a "lost-update" and other complications. And, again of course, full metadata can be deleted at the command-line. |!note| |0Microsoft Metadata| |^ An example of such property meta-data generated by a Microsoft Windows (not Internet) Explorer client (example wrapped for presentation): |code| Tue, 26 Jun 2007 02:00:48 GMT Mon, 23 Jul 2007 01:52:32 GMT Mon, 23 Jul 2007 01:52:32 GMT 00000020 |!code| |^ Every file written or modified by |/Windows Explorer| generates this sort of metadata which is then stored in an associated metadata file and read each time the data file is accessed. Some might consider this unnecessary clutter in most circumstances (I do). WASD allows this metadata to be suppressed and equivalent data generated (fudged) from file |/live| properties when accessed - often sufficient for purpose. To suppress the actual processing of |/Windows Explorer| metadata set a path using the WEBDAV=NOWINPROP in WASD_CONFIG_MAP. |code| set /webdav/* webdav=NOwinprop |!code| |2WebDAV Locking| |^ For efficiency and functionality considerations WebDAV locking may be enabled and disabled (default) as global functionality using the WASD_CONFIG_GLOBAL [WebDAVlocking] directive. Additionally the WEBVDAV=[NO]LOCKING path SETing can configure this on a per-path basis. |0Write Access Only| |^ In common with RFC 4918 WASD WebDAV locking controls only write access. Both exclusive and shared locks are provided. Locking applies to the DELETE, LOCK, MKCOL, MOVE, PROPPATCH, PUT, and UNLOCK methods. |0Locking Depth| |^ WASD WebDAV locking checks parent collections to a configurable depth. WASD_CONFIG_GLOBAL directive [WebDAVlockCollectionDepth] where the default (0 or 1) checks only WebDAV locking on files, 2 WebDAV locking on the parent directory, 3 on the grandparent, 4 the great-grandparent, etc. Of course each level can add significant latency (and expense) to some operations. |note| |0Lock Depth 0| Real world experience has suggested locking depth should be maintained at the default 0 (or 1), allowing the client explicitly to manage and negotiate hierarchies of locking if required. WebDAV clients (probably correctly) assume a minimally compliant and relatively unsophisticated WebDAV server. |!note| |^ For more information on locking operation and implementation details see the DAVLOCK.C module and for meta-data in general the DAVMETA.C module. |0Locking Timeout| |^ When a client locks a resource it can specify the period for the lock. In the absence of such a specification WASD will apply the [WebDAVlockTimeoutDefault] value (by default 0-01:00:00 - one hour). WASD also applies the [WebDAVlockTimeoutMax] maximum lock period (by default 7-00:00:00 - one week). When the maximum period expires the lock is no longer valid. |0VMS DLM Locking| |^ WASD uses VMS locking to queue and arbitrate access to WebDAV resources and meta-files. |^ Two lock modes are employed; 'exclusive', when changes are to be made to the resource or its meta-data, and 'concurrent read', when resource and/or meta-data are only to be read. Concurrent read locks are compatible, but an exclusive queued against a resource currently being read waits, as does a read against a current exclusive. |^ WASD takes out its own VMS DLM locks on resources (files and directories) before beginning any WebDAV operation, and these prevent conflict with other WASD WebDAV operations on the same system or cluster, but RMS does not use these nor does WASD use RMS locks (except when actually acessing the file-system of course), and so there is potential for interactions between the two domains (in common with general file-system actvities). WASD WebDAV deliberately does not try to block file-system actions from other processing (except where RMS locks/blocks). Its own DLM locking is purely for internal purposes. |2Some Wrinkles| |^ Some application/environment-specific considerations when using WASD WebDAV. Please report any you encounter for future inclusion in this section. Also see |link|Microsoft Miscellanea| immediately below. |3OS X Finder| |^ OS X Finder requires [WebDAVlocking] enabled for read/write access, otherwise access will be read-only. |3Gnome/gvfs/Nautilus| |^-As at publication, |/Gnome/gvfs/Nautilus| has quite a number of behavioural problems with associated Bugzilla items. Don't expect it to behave well! This has been my experience. |3Dreamweaver| |^ Dreamwever 8 (at least, the only version I have access to) insists on using a URI with a trailing "/./" occasionally (I'm guessing to specify the "current" directory - cf. "/../", or "parent" syntax). Just absorb this internally using an appropriate mapping internal redirect. |code| redirect /webdav/**/./ /webdav/*/ |!code| |2Microsoft Miscellanea| |^ A cornucopia of of minor and major considerations! |note| |0much of this is pre- Windows 10| and relates to Windows 7, Windows XP and possibly earlier. Windows 10 and WebDAV behaviour is very much an unknown quantity. The following information continues to be included for historical reference only. |!note| |^ Microsoft approach WebDAV in their own inimitable fashion. Hence Microsoft agents, considering their ubiquity, including their mini-redirector are specifically looked for and functionality modified to accomodate them. |^ The following is a list topics/issues that were encountered/investigated during WASD WebDAV development. They may or may not be applicable to your site. |^ Some general references: |simple#| |& |%http://greenbytes.de/tech/webdav/webdav-redirector-list.html| |& |%http://greenbytes.de/tech/webdav/webfolder-client-list.html| |& |%http://www.zorched.net/2006/03/01/more-webdav-tips-tricks-and-bugs/| |& |%http://www.webdavsystem.com/server/documentation/troubleshooting| |& |%http://www.webdavsystem.com/documentation/troubleshooting| |& |%http://code.google.com/p/sabredav/wiki/Windows| |& |%http://ulihansen.kicks-ass.net/aero/webdav/| |& |%http://chapters.marssociety.org/webdav/| |!simple| |^ DOS/Windows command-line network configuration: |code| C:\\> NET USE Z: http://the.host.name/folder/ C:\\> NET USE Z: /DELETE |!code| |3Mapping| |^ Microsoft agents (at least) seem to request the server OPTIONS of the server root regardless of any path provided with the NET USE or other network drive mapping employed. To selectively map such a request into a path that has WebDAV enabled on it (and will therefore respond with the DAV-related options) use a conditional redirect rule. For example |code| if (webdav:) if (request-method:OPTIONS) redirect / /dav-path/ endif |!code| or if only required for MS agents then something more specific |code| if (webdav:MSagent) if (request-method:OPTIONS) redirect / /dav-path/ endif |!code| |^ Subsequent rules will probably be required to map typeless directory requests to the actual directory required. |code| redirect /dav-path /dav-path/ pass /dav-path/* /dav_root/* webdav=read |!code| |3FrontPage Extensions| |^ Requests containing paths /_vti_inf.html and /_vti_bin/* are related to FrontPage protocol discovery probing. They can be adequately handled using a mapping rule lsuch as the following: |code| pass /_vti_* "404 Not an MS platform!" |!code| |3Avoiding Microsoft Property Clutter| |^ See |link|Microsoft Metadata||. |3OPTIONS header "MS-Author-Via: DAV"| |simple| |& |%http://msdn2.microsoft.com/en-us/library/ms691698.aspx| |!simple| |^ If the server's response does not contain an MS-Author-Via header, the OLE DB Provider for Internet Publishing loads the WEC and WebDAV protocol drivers one at a time (WEC first, WebDAV second) and asks them, "Do you know how to handle this URL?", specifying the exact URL passed in by the client. The first protocol which responds "yes" is selected. If neither protocol driver responds "yes" then the method which triggered the automatic driver selection (usually IBindResource::Bind) fails with an OLE DB Provider for Internet Publishing specific error code IPP_E_SERVERTYPE_NOT_SUPPORTED. |3Repairing broken XP Web Folders| |simple| |& |%http://chapters.marssociety.org/webdav/| |!simple| |^ Some Windows XP machines have a broken Web Folders installation. Microsoft includes a Web Folders repair utility built in to Windows to correct the problem. Use the following steps to fix the problem: |number| |& Click on the "Start" menu in the lower left corner, and select "Run..." |& Type in "webfldrs.msi" and click the "OK" button. |& Click on the "Select reinstall mode" button. |& Select *ALL* of the checkboxes *except* for the second one ("Reinstall only if file is missing"). |& Click on the "OK" button. |& Click on the "Reinstall" button. |& After the reinstallation is complete, reboot the computer. |!number| |3Adding a port number to the webfolder-address| |^ Attach the port-number (80 by default) to the http-address you enter into the field of the "My Network Places"-assistant. As you can see in the following image and the linked screenshot, this will force Windows XP to use the "Microsoft Data Access Internet Publishing Provider DAV 1.1" mechanism instead of "Microsoft-WebDAV-MiniRedir/5.1.2600". |3Adding a number-sign ("#") to the webfolder-address| |^ It is also possible to add the number sign # to the http-address you enter into the field of the "My Network Places"-assistant. As you can see in the following image and the linked screenshot, this will also force Windows XP to use the "Microsoft Data Access Internet Publishing Provider DAV 1.1" mechanism instead of "Microsoft-WebDAV-MiniRedir/5.1.2600". |code| http://the.host.name/folder# |!code| |3Force Windows XP to use Basic Authentication| |^ There is a third way to get this working from the client-site. As described in the Microsoft Knowledge Base, Article ID: 841215, Windows XP disables "Basic Auth" in his "Microsoft-WebDAV-MiniRedir/5.1.2600"-mechanism by default for security reasons. See description below. |3Microsoft XP Explorer BASIC Authentication| |simple| |& |%http://www.microsoft.com/technet/prodtechnol/winxppro/\ maintain/sp2netwk.mspx| |!simple| |^ You can enable BasicAuth by adding the following registry key and setting it to a non-zero value: |code| HKEY_LOCAL_MACHINE\\SYSTEM \\CurrentControlSet\\Services\\WebClient\\Parameters\\UseBasicAuth (DWORD) |!code| |^ If you delete the registry key or set it to 0, the behavior reverts to the default, or disabling the use of BasicAuth. |^ Disabling Basic Authentication over a clear channel: |^ Because the DAVRdr is part of the remote file-system stack, a computer is open to attack whenever an attempt is made to remotely access files. Although the threat to other applications that use the Internet APIs is less severe than it is for the DAVRdr, a similar attack is possible whenever an application (or the user) attempts to access a URL. For this reason, WinInet is exposing the mechanism by which the DAVRdr disables BasicAuth to other users of the Internet APIs. |^ With Windows XP Service Pack 2, there are two ways to block the use of Basic Authentication over clear (or unencrypted) channels: |^ Create the following registry key and set it to a non-zero value. |code| HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion \\InternetSettings\\DisableBasicOverClearChannel (DWORD) |!code| |^ This prevents WININET from attempting to use BasicAuth unless the channel is secured (HTTPS or SSL). |^ The application can disable the use of BasicAuth for its connections by setting the AUTH_FLAG_DISABLE_BASIC_CLEARCHANNEL flag (0x4) in the value supplied in the call to InternetSetOption using INTERNET_OPTION_AUTH_FLAGS. |^ |**** AND THEN RESTART WINDOWS ***|| |3Microsoft Windows 7 BASIC Authentication| |^ You can enable BasicAuth by setting the following registry key to the value 3 and restarting the WebClient service: |code| HKEY_LOCAL_MACHINE\\SYSTEM \\CurrentControlSet\\Services\\WebClient\\Parameters\\BasicAuthLevel (DWORD) |!code| |3Error 0x800700DF: The file size exceeds the limit allowed and cannot be saved| |^ "In my case I try to copy file over WEBDAV to WEB Client connection e.g. I have mapped drive to web site. file is about 70MB I can copy small files from the same WEBDav folder." |code| HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\WebClient\\Parameters |!code| |number| |& Right click on the FileSizeLimitInBytes and click Modify |& Click on Decimal |& In the Value data box, type 4294967295, and then click OK. Note this sets the maximum you can download from the Webdav to 4 gig at one time, I havent figured out how to make it unlimited so if you want to download more you need to split it up. |!number| |simple| |& |%http://social.answers.microsoft.com\ /Forums/en/xphardware/thread/d208bba6-920c-4639-bd45-f345f462934f| |!simple| |2References|| |^ These are the resources used during WASD WebDAV development. |bullet| |item| WebDAV in general: |simple#| |& |%http://webdav.org/| |& |%http://en.wikipedia.org/wiki/Webdav| |& |%http://tools.ietf.org/html/rfc4918| |& |%http://tools.ietf.org/html/rfc4331| (quota) |& |%http://tools.ietf.org/html/rfc2518| (obsoleted by RFC 4918) |!simple| |item| WebDAV: Next-Generation Collaborative Web Authoring |^-Lisa Dusseault, 2003 ISBN: 0130652083 |item| Using Expat by Clark Cooper: |simple#| |& |%http://en.wikipedia.org/wiki/Expat_(XML)| |& |%http://www.xml.com/pub/a/1999/09/expat/index.html| |& |%http://www.xml.com/lpt/a/47| |!simple| |!bullet| |0Client Tools|| |^ All these have been used during WASD WebDAV development. |bullet| |item|A comprehensive but not exhaustive list |^-|%http://www.webdavsystem.com/server/access/| |^-|%http://www.webdavsystem.com/server/access/clients_comparison| |item|DAVExplorer - a Java-based GUI Explorer-style file navigation tool |^-|%http://www.davexplorer.org/| |item|cadaver - a command-line WebDAV client for *x |^-|%http://www.webdav.org/cadaver/| |item|davfs2 - a mountable WebDAV file-system for Linux |^-|%http://savannah.nongnu.org/projects/davfs2| |item|The WebDAV URL handling of KDE 4.2 Dolphin (v1.2) |^-|%http://www.webdavsystem.com/server/access/konqueror| (yup, I know!) |^-In contrast to Gnome as reported below, KDE and its KIO/Dolphin behave extrordinarily well. |item|The WebDAV URL handling of Gnome Nautilus (2.26.2, gvfs/1.2.2) |^-|%http://www.webdavsystem.com/server/access/gnome_nautilus| |^-As at publication, |*Gnome/gvfs/Nautilus has quite a number of behavioural problems| with associated Bugzilla items. Don't expect it to behave reasonably! |item|The WebDAV handling of Apple Mac macOS X Finder |^-|%http://www.webdavsystem.com/server/access/macosx| |item|Windows Explorer - and the associated mini-director, et.al., on XP (not Vista). |^-See |\|link|(hd_webdav_microsoft_misc)| below. |item|Another Windows option - try before you buy (i.e. commercial product). |^-"WebDrive is more than just an FTP Client." Indeed! It's functional WebDAV drive-letter client. |^-|%http://www.webdrive.com/| |item| |*And if you really need effective WebDAV on a Windows platform ...|| |^-"BitKinex integrates the fuctionality of an innovative FTP, SFTP and WebDAV client for Windows." |^-|*And it's FREEWARE!|| |^-|%http://www.bitkinex.com/| |!bullet|