Warning: This document is for an old version of RDFox. The latest version is 7.2.

13. RDFox Endpoint

The RDFox Endpoint provides REST access to the process’s RDFox server (see Section 4) and also serves the HTML, JavaScript and other static assets for the RDFox Console. For a description of the RDFox REST API, see Section 14.

13.1. Starting and Stopping the Endpoint

The endpoint can be started in the following ways:

  • By launching the RDFox process in daemon mode (see Section 16.1).

  • By issuing endpoint start within the RDFox shell (see Section 16.2.2.16). When started in this manner, the endpoint accesses the same RDFox server as the shell, so the effects of any commands that affect the state of the server (e.g., dstore create) will be immediately visible on the endpoint.

  • By issuing daemon within the RDFox shell (see Section 16.2.2.10).

13.2. Endpoint Parameters

The configuration of the endpoint is determined by the parameters below. It is not possible to modify the configuration of the endpoint once it is listening however, in the shell, the endpoint can be stopped and restarted with new parameter values.

  • port determines the port at which the endpoint is started. The port can be specified as a verbatim port number or as a TCP service name. The default is 12110. For legacy reasons, the port can also be specified using service-name; moreover, if both options are present, then port takes precedence.

  • num-threads determines the number of threads that endpoint will use to process RESTful requests. The default value is one less than the number of logical processors of the machine on which RDFox is run.

  • channel determines the connection type that the endpoint should use.

    • unsecure means the endpoint will use the unsecured HTTP connection. This is the default value.

    • ssl means the endpoint will use SSL/TLS using the platform’s native secure communication package. On macOS this is Secure Transport, and on Linux and Windows this is openSSL.

    • open-ssl means the endpoint will use SSL/TLS implemented using the openSSL package. This option is available on all platforms.

  • The following parameters determine the SSL/TLS configuration for the endpoint.

    • credentials specifies the server certificate and private key, and the intermediate certificates as a verbatim string in PEM format. The string must contain the server’s private key, the server’s certificate, and zero or more intermediate certificates. For example, this file could look as follows:

      -----BEGIN RSA PRIVATE KEY-----
... server key ...
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
... server certificate ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... 1st intermediate certificate ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... 2st intermediate certificate ...
-----END CERTIFICATE-----

    • credentials-file specifies the name of the file whose content contains the credentials. The file content must have the same format as the credentials parameters.

    • credentials-name specifies the comma-separated list of names of items in the system’s keystore. The first name must identify a certificate and a private key, which are used as a main identity of the server. The remaining names identify intermediate certificates. This option is available only on macOS, where the keystore is the system’s keychain.

    • credentials-passphrase provides the passphrase that can be used to unlock the credentials in case they are encrypted. This parameter is optional.

    • min-secure-protocol determines the minimum protocol version that the server should use. The allowed values are ssl2, ssl3, tls1, tls11, tls12, and tls13. The default value is tls12.

  • channel-timeout determines the length of time that the endpoint will wait for I/O while servicing HTTP(S) requests. That is, if the endpoint tries to read from or write to the TCP connection, the respective I/O will wait for for the specified duration before giving up. This option ensures endpoint resilience in the face of slow or buggy HTTP(S) clients. The accepted values are unlimited, meaning that the HTTP client will wait forever for each I/O, or a duration specified as an integer followed by an optional space and optional unit. Accepted units are s or ms. An integer with no unit is interpreted as a number in seconds. The unlimited setting should be used only when there are valid reasons for I/O operations to take a long time and clients are known to be correct. The default value is 60 seconds.

  • max-idle-connections determines the maximum number of connections to the server that can be idle at any point in time. Once this limit is exceeded, RDFox endpoint will close all idle connections (even those that have been idle for less than connection-keep-alive-time) in order to free resources and thus provide uninterrupted service to users. For this option to be effective, it should be set to some value lower than the maximum number of file descriptors for the RDFox process. On Window, the default value for this parameter is 1024. On Linux and macOS, the default value is set to 90% of the maximum number of file descriptors for the server process.

  • connection-keep-alive-time determines the maximum time in seconds that an HTTP connection will be kept open between requests. That is, if a client opens a TCP connection to the endpoint and makes a request, the server will wait for the specified amount of time to receive another request on this connection; if no request is issued in the specified time, the server will close the connection. The value of 0 means that the server should close the TCP connection after every request. The default value is 90 seconds.

  • listening-backlog determines the TCP listening backlog for the socket accepting the connection. The default value is 10.

  • receive-buffer and send-buffer determine the sizes in bytes of the receive and send buffers for the sockets servicing the requests. The default values are zero, which means that the system will determine the buffer sizes depending on the properties of the connection. For more information, please refer to the SO_RCVBUF and SO_SNDBUF socket options.

  • object-keep-alive-time specifies the time in seconds that the endpoint will keep cached cursors, connections or shells between requests. During its operation, the endpoint retains certain objects between requests either for performance reasons (e.g., the endpoint may cache cursors of partially evaluated queries) or to ensure its operation (e.g., the endpoint will maintain named server and data store connections). In order to prevent these objects from accumulating indefinitely, the endpoint will delete each object after it has not been used for the specified amount of time. The default value for this parameters is 60 seconds.

  • access-control-allow-origin configures the RDFox endpoint for Cross-Origin Resource Sharing (CORS). When this option is set, RDFox will include, in response to CORS requests, all the headers necessary to allow cross-origin usage of the REST API by the specified origin or origins. The value * can be set to allow use of the REST API by any origin, however such usage will be restricted to anonymous requests (see Section 13.3) due to the CORS specification’s rules on credentials (see this section of the CORS specification). If the value is not set to *, it must be set to a single origin such as https://example.org or http://localhost:8080 to allow requests from just that origin. When this option is unset (the default), RDFox will not add any CORS headers to its responses.

  • protocol determines which network layer protocol the endpoint will use.

    • IPv4 means the endpoint will use Internet Protocol version 4.

    • IPv6 means the endpoint will use Internet Protocol version 6.

    • IPv6-v4 means the endpoint will use Internet Protocol version 6 if possible or Internet Protocol version 4 if not. This is the default value.

  • The following parameters determine the configuration for HTTP request logging (see also Section 17.2).

    • request-logger determines how each serviced HTTP request is logged. All logging goes to standard output.

      • none disables request logging. This is the default value.

      • clf enables request logging using the Common Log Format.

      • elf enables request logging using the Extended Log Format. The exact content of each log entry is determined by the elf-logger-fields parameter. Each log entry is limited to 10 KiB. Where an entry would exceed this limit, the elided fields are indicated with ....

    • elf-logger-fields determines which fields are logged by the extended log format logger. This parameter has no effect unless request-logger is set to elf. The value for this parameter must be a space-delimited list of the following field identifiers: date, time, time-taken, c-ip, c-port, cs({HEADER}), cs-bytes, cs-method, cs-uri, cs-uri-query, cs-uri-stem, sc({HEADER}), sc-bytes, sc-status, x-role-name, x-socket-exception. The identifier x-role-name specifies the role name with which the request was made. The identifier x-socket-exception specifies the textual description of any exception raised when the endpoint attempts to accept a socket connection. All other identifiers have the meanings defined in the draft specification. The default value for this parameter is date time cs-method cs-uri-stem sc-status sc-bytes time-taken.

  • The following parameters determine the configuration for time limits on the evaluation of SPARQL queries.

    • query-time-limit determines the maximum time in seconds that a request for query evaluation can take; if a query request is not completed in that time, query evaluation will be stopped. The default value is 30. The value of unlimited removes any time limits on query evaluation.

    • allow-query-time-limit-override is a Boolean value specifying whether a query request can override the time limit on query evaluation. If this option is set to true or yes, then each query evaluation request can use the Query-Time-Limit header to specify the query time limit to be used for the current request. The value of the Query-Time-Limit header follows the same syntax as the query-time-limit endpoint parameter. The default value is false.

13.3. Anonymous Requests and the guest role

Upon receiving a REST request with no Authorization header, the RDFox endpoint will attempt to authenticate as role guest. If this authentication succeeds, the endpoint will then continue processing the request using the resulting connection. The level of access to an RDFox server available via anonymous (i.e. unauthenticated) requests can therefore be controlled by granting the appropriate privileges to the guest role or, in the case that all requests should be authenticated, ensuring that guest is not one of the server’s roles.

For more details on access control, see Section 11.