Creating a New WebDAV Server
To create a new server, follow these steps:
Click Groups in the left tree menu.
Click the group in which you want to define the WebDAV server (for example, Default).
Click App Servers in the left tree menu.
Click the Create WebDAV tab.
The WebDAV Server page appears.
Go to the Server Name field and enter a shorthand name for this WebDAV server.
MarkLogic Server will use this name to refer to this server on display screens and in user interface controls.
Go to the Root field and enter the name of WebDAV root. This root is a string that represents the top-level of the WebDAV URI hierarchy. Any document accessible through this WebDAV server must have a URI that begins with this root string. For more details on the root, see Server Root Directory.
If the root directory does not contain a forward slash, the Admin Interface adds one for you.
Go to the Port field and enter the port number through which you want to make this WebDAV server available. The port number must not be assigned to any other server.
Go to the Database field and select the database to be accessed by this WebDAV server.
Multiple HTTP, ODBC, XDBC, and WebDAV servers can be connected to the same database.
Note
If you are using a database with a WebDAV server, the directory creation setting on the database should be set to
automatic, which will automatically create the root directory and other directories for any documents added to the database (if the directory does not already exist). For more information on directories, see Directories.Scroll to the Authentication field. Select an authentication scheme, as described in Types of Authentication in Securing MarkLogic Server. The default is digest, which uses encrypted passwords.
If you select application-level authentication, you will also need to fill in a Default User. Any one accessing the App Server is automatically logged in as the Default User until the user logs in explicitly.
Warning
If you use an admin user (admin) as the Default User (an authorized administrator with the
adminrole), then everyone who uses this App Server is automatically a user with theadminrole, which effectively turns off security for this App Server.Scroll to the Privilege field near the bottom of the screen. This field represents the privilege needed to access (login) the server. You may leave this field blank.
Set any other properties for this App Server, as appropriate to your needs:
Last Login and Display Last Login are described in Storing and Monitoring the Last User Login Attempt.
Backlog specifies the maximum number of pending connections allowed on the HTTP server socket.
Threads specifies the maximum number of App Server threads.
Request Timeout specifies the maximum number of seconds before a socket receives a timeout for the first request.
Keep Alive Timeout specifies the maximum number of seconds before a socket receives a timeout for subsequent requests over the same connection.
Session Timeout specifies the maximum number of seconds before an inactive session times out.
Max Time Limit specifies the upper bound for any request's time limit. No request may set its time limit (for example with
xdmp:set-request-time-limit()) higher than this number. The time limit, in turn, is the maximum number of seconds allowed for servicing a query request. The App Server gives up on queries which take longer, and returns an error.Default Time Limit specifies the default value for any request's time limit, when otherwise unspecified. A request can change its time limit using
xdmp:set-request-time-limit(). The time limit, in turn, is the maximum number of seconds allowed for servicing a query request. The App Server gives up on queries which take longer, and returns an error.Static Expires adds an "expires" HTTP header for static content to expire after this many seconds.
Pre-commit Trigger Limit specifies the maximum number of pre-commit triggers a single statement against this App Server can invoke. For more information on triggers, see Using Triggers to Spawn Actions in the Application Developer’s Guide.
Pre-commit Trigger Depth specifies the maximum depth (how many triggers can cause other triggers to fire, which in turn cause others to fire, and so on) for pre-commit triggers that are executed against this App Server. For more information on triggers, see Using Triggers to Spawn Actions in the Application Developer’s Guide.
Collation specifies the default collation for queries run in this appserver. This will be the collation used for string comparison and sorting if none is specified in the query. For details, see Encodings and Collations in the Search Developer’s Guide.
Concurrent Request Limit specifies the maximum number of requests any user may have running at a specific time. 0 indicates no maximum. For details, see Managing Concurrent User Requests.
Log Errors specifies whether to log uncaught errors for this App Server to the ErrorLog.txt file. This is useful to log exceptions that might occur on an App Server for later debugging.
Debug Allow specifies whether to allow requests against this App Server to be stopped for debugging, using the MarkLogic Server debugging APIs.
Profile Allow specifies whether to allow requests against this App Server to be profiled, using the MarkLogic Server profiling APIs. For details, see Profiling Requests to Evaluate Performance in the Query Performance and Tuning Guide.
Default XQuery Version specifies the default XQuery language for this App Server if an XQuery module does explicitly declare its language version.
Multi Version Concurrency Control specifies how strict queries behave about getting the latest timestamp. This only affects query statements, not update statements. For details about queries and transactions in MarkLogic Server, see Understanding Transactions in MarkLogic Server in the Application Developer’s Guide.
The properties associated with SSL support are described in Configuring SSL on App Servers in Securing MarkLogic Server.
Scroll to the top or bottom and click OK.
The new WebDAV server is added. Adding a WebDAV server is a “hot” admin task.