Q:

Is there a way to make BaseX serve an HTML document?

Is there a way to make BaseX's HTTP server serve an HTML document stored either in the db as a raw resource or in the file system, with a text/html content type, so it can be displayed in a browser?
The document is a web page that does XHR requests to BaseX.  Currently, I load it on the browser through the file protocol.  This necessitates making Jetty to respond with CORS headers, or else the same origin policy blocks the XHR requests.
However, this is a maintenance burden.  Every update to BaseX requires manually getting a new version of the servlet filter that adds the CORS headers.
I'd like to have BaseX itself serve the HTML document (and become the origin), thus eliminating the cross origin requests.
Is it possible?

A:

The default web.xml (located in BaseXWeb/WEB-INF) already includes configuration to serve static files from the ./static directory under the /static/ URI:
  <!-- Mapping for static resources (may be restricted to a sub path) -->
  <servlet>
    <servlet-name>default</servlet-name>
    <init-param>
      <param-name>useFileMappedBuffer</param-name>
      <param-value>false</param-value>
    </init-param>
  </servlet>
  <servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>/static/*</url-pattern>
  </servlet-mapping>

You can also have a look at the BaseX DBA, which also acts as an example implementation of web applications hosted by BaseX and makes use of the ./static folder for some JavaScript files.
Of course, you could also change the default web.xml if you require the files hosted from another directory. An alternative would always be to store the documents in a database as RAW files, and serve them with adequate content type on your own. As hosting files through the ./static folder bypasses RestXQ execution and has Jetty offer the files directly, you might have some performance improvements over reading files from BaseX databases, though. A third solution might be to host a reverse proxy in front of BaseX to serve the static files (which is usually be done for production anyway), but this adds some administrative overhead in development.

