Concepts [v2]

The version 2 of the webdav-server module comes with new concepts and make some concepts of the version 1 obselete.

The class WebDAVServer will make the interface between the HTTP interface and the file systems.

The file systems are the managers of a sub-tree of the server.

server.setFileSystem('/folder1', myFileSystem, callback);

Doing so will tell the server that if a user make a request on the resource /folder1 or one of its children (/folder1/file2, /folder1/folder2/file3, etc...), the myFileSystem will be used. If the client request on the resource /folder2, it is not mapped to myFileSystem, then it will call the closest parent file system, which is the root file system (mapped on /).

The file systems have the role to manage the mapping of its children (which allow a lazy mapping and non-persistent mapping, useful for interfacing a remote server), their content, their properties and their locks.

A file system must inherit from the FileSystem class which implements a lot of methods to help managing the resources. The sub-class can implement only a part of the methods, letting the FileSystem class to use its default behaviour.

This mapping system allow to map file systems in other file systems. For instance, you can use a PhysicalFileSystem to map a real folder on the disk and map in its children a VirtualFileSystem. This way, /folder1 will be a real folder on the disk but /folder1/virtualFolder will not be on the disk but in memory only. With this system, you can map whatever file system you want wherever you want, such as a FTP file system (to display the content of a remote FTP server).

Because each method call to a file system requires a RequestContext (the context of the request) and a Path (the path to the resource in the file system : /folder1/folder2/file3 in the file system mapped in /folder1 will have a path equals to /folder2/file3), it is possible to wrap these arguments in an object, making the use of the module in JavaScript or in TypeScript far easier and lighter. Those classes are :

• ContextualFileSystem which wrap the RequestContext
• Resource which wrap the RequestContext and the Path

In opposite to the version 1, the resource concept is just an interface to ease the use of the file system, and needs to development from the module user when creating a custom file system.

This way, instead of doing :

// myFileSystem mapped on /folder1
server.getFileSystem('/folder1/file2.txt', (fs, rootPath, subPath) => {
    // Here, subPath === '/file2.txt'
    fs.readDir(ctx, subPath, (e, files) => { /* [...] */ });
})

you can do this :

server.getResource(ctx, '/folder1/file2.txt').readDir((e, files) => { /* [...] */ });

or :

ctx.getResource('/folder1/file2.txt').readDir((e, files) => { /* [...] */ });

Here, ctx is the RequestContext. It will be created with the information from the request, carry the response object for the server and it is a tool kit. If created from outside of a HTTP request, it is possible to create an external RequestContext instance :

const ctx = server.createExternalContext();

There are some options allowing you to define the user, the headers as if it was from a HTTP request, the url, etc...