foXServe 1.3

The term also refers to the set of extensions to the HTTP protocol that the group defined which allows users to collaboratively edit and manage files on remote web servers.

The WebDAV protocol's aim was to make the World Wide Web a readable and writable medium, in line with Tim Berners-Lee's original vision. It provides functionality to create, change and move documents on a remote server (typically a web server or "web share"). This is useful, among other things, for authoring the documents which a web server serves, but can also be used for general web-based file storage that can be accessed from anywhere. Important features in WebDAV protocol include locking (overwrite prevention), properties (creation, removal, and querying of information about author, modified date, etc.), name space management (ability to copy and move Web pages within a server's namespace) and collections (creation, removal, and listing of resources).

How do I use WebDAV to upload files and Resources?

WINDOWS XP : Using the Add Network Place Wizard

Using the Add Network Place Wizard in Windows XP, you can add a shortcut to your computer that allows you to upload and access files in Drop Box or Resources using WebDAV. To do so, follow these steps:

1. On the desktop, double-click My Network Places.

2. In the "Network Tasks" pane, click Add a network place.

3. On the welcome screen, click Next.

4. Select Choose another network location, and then click Next.

5. In the "Internet or network address:" field, enter a URL like this: http://<your ip>/test

6. Connect

MAC OS X:

Choose "connect to server" from the Finder's GO menu (the shortcut is ⌘ K).

Provide the URL http://<your ip>/test in the server address field. Hit connect, and the volume will appear on your desktop.

LINUX:

Follow the documentation provided with your distribution. For FEDORA Choose "Connect to server" from resources entry on top bar, choose from type of service popup WEBDAV (HTTP) and specify:
Server: <your ip>
path: test
and then click on Connect, the volume test will appear on your desktop.

Loading/Unloading the DAV Module (already loaded by default)

foXServe is equipped with mod_dav, linked in the default configuration and active in the http://<your ip>/test without any access restriction. Please, follow the guidelines to apply access control to the server.

Apache must be informed about the mod_dav module through the Addmodule and LoadModule directives. LoadModule is used when mod_dav is dynamically loaded. These configuration lines are (normally) inserted automatically on the Unix platforms (by APXS or the Apache build process).
(this information is here for reference; if Apache does not recognize the mod_dav directives such as DAV or DAVLockDB, then you may be missing these configuration lines)

dynamic loading:

Loadmodule /usr/local/apache/libexec/libdav.so
Addmodule mod_dav.c

statically linked:

Addmodule mod_dav.c

Enabling DAV

Configuring the mod_dav module is quite simple, actually. Within a <Directory> or <Location> directive in your Apache configuration file (i.e. /etc/httpd.conf), simply insert the following line:

DAV On

If the DAV directive is within a <Directory> directive, then DAV will be enabled for that particular directory and its subdirectories. For a <Location> directive, then DAV will be enabled for that portion of the URL namespace.
The Lock Database

Next, add a DAVLockDB directive at the top-level of your configuration file (i.e. outside of a <Directory> or <Location> directive). This directive should specify a filename that mod_dav will create. The directory should exist and should be writable by the web server process.

Note: the directory should not be on an NFS-mounted partition. mod_dav uses flock/fcntl to manage access to the database. Some operating systems cannot use these operations on an NFS-mounted partition.

In the following example, the DAV lock database will be stored in the /usr/local/apache/var directory (which must be writable by the server process). The file's name will be DAVLock when mod_dav needs to create it.
(actually, mod_dav will create one or more files using this file name plus an extension)

DAVLockDB /var/tmp/dav/DAVLock

The DAVLockDB directive can appear outside of any container or within a <VirtualHost>, it only needs to appear once, and a file extension should not be supplied.
Lock Timeout Minimums

An optional directive, DAVMinTimeout, specifies the minimum lifetime of a lock in seconds. If a client requests a lock timeout less than DAVMinTimeout, then the DAVMinTimeout value will be used and returned instead. For example, Microsoft's Web Folders defaults to a lock timeout of 2 minutes; 10 minutes could be used to reduce network traffic and the chance that the client might lose a lock due to network latency.

The DAVMinTimeout directive is optional, and may be used on a per-server or per-directory/location basis. It takes a single, non-negative integer. Since this value represents a minimum allowed, setting it to zero (0) will disable this feature. The default value for DAVMinTimeout is zero.
Preventing "Depth Infinity" PROPFINDs

A PROPFIND request with a Depth:&nbspInfinity header can impose a large burden on the server. These kinds of requests could "walk" the entire repository, returning information about each resource found. mod_dav builds the response in memory, so these kinds of requests could potentially consume a lot of memory (the memory would be released at the end of the request, but the peak can be quite large).

To prevent these kinds of requests, the DAVDepthInfinity directive has been provided. It is a simple on/off directive, which can be used on a per-server or a per-directory/location basis. The default value for this directive is off, meaning these kinds of requests are not allowed.

NOTE: the WebDAV Working Group has stated that it is acceptable for DAV servers to refuse these kinds of requests. Properly written client software should not issue them, and you should not worry about disabling them.
Limiting XML Request Body Sizes

mod_dav will parse XML request bodies into memory. It would be a very effective "Denial of Service" attach to send a large request body at a mod_dav server. Apache defines a directive named LimitRequestBody which will limit all methods' request bodies. Unfortunately, this is not an effective mechanism for a mod_dav server since large PUT operations should be allowed.

To limit just the methods that have an XML request body, mod_dav defines the LimitXMLRequestBody directive. The default for this value is a compile-time constant, which is set to one million (1000000) bytes in the standard distribution. Setting the value to zero (0) will disable the size limit.

LimitXMLRequestBody may be set on a per-server or a per-directory/location basis, and takes a single non-negative integer argument.
Sample Configuration

The default configuration segment look like:
...
DAVLockDB /var/tmp/dav/DAVLock
DAVMinTimeout 600

<Location /test>
DAV On
</Location>
...
Limiting DAV Access to Authorized Users


Access control is a really important aspect of "WEB SHARES". You can apply controls following the directive of DocumentRoot. For example this is a configuration using a .htpasswd file:

<Location /test>
DAV On
AllowOverride None
Options None
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /mnt/flash/.htpasswd
# only authenticated users may access the repository
Require valid-user
</Location>

the .htpasswd file is generated by htpasswd command:

htpasswd -c .htpasswd kanta
New password:
Re-type new password:

The command create a file named ".htpasswd" that contains username and password.

Follow Authentication, Authorization, and Access Control apache manual for a complete explanation of basic auth and digest auth.

The DAV and DAVLockDB directives are the only two configuration changes necessary to operate a DAV server. However, it is usually best to secure the site to be writable only by specific users. This requires the use of the <Limit> directive. Here is an example:
<Location /mypages>
DAV On
<Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user kanta
</Limit>
</Location>

The above configuration will allow only authorized users to manipulate the site. However, it does allow them a bit more freedom than you may like. In particular, they may be able to place a .htaccess file into the target directory, altering your server configuration. The server may have already been configured to not read .htaccess files, but it is best to make sure. Also, you may want to disallow other options within the DAV-enabled directory -- CGI, symbolic links, server-side includes, etc. Here is a modified configuration with the additional restrictions placed on it:
<Location /test>
DAV On
AllowOverride None
Options None
<Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user kanta
</Limit>
</Location>
Using LimitExcept

Rather than using the <Limit> directive and specifying an exhaustive list of HTTP methods to secure, it is also possible to use the <LimitExcept> directive. This directive applies the access restrictions to all methods except for the methods listed. For example, your configuration section might look like:
<Location /test>
DAV On
AllowOverride None
Options None
<LimitExcept GET HEAD OPTIONS>
require user kanta
</LimitExcept>
</Location>

Choosing to use one or the other is a matter of preference. The <Limit> directive is precise and explicit, but the <LimitExcept> directive will automatically restrict methods that are added in the future.