High level overview
Soon to come...
All incoming requests are enqueued in the request queue
that one of the worker threads will process. Worker threads are taken from a thread pool which will dynamically resize its size based on the request load as long as the
Worker threads delegate the request processing to the web server, that will flow it through the following pipeline:
Each step corresponds to an event that a registered Module
can handle, and any subsequent step can be omitted if the module cancels the running pipeline on any reason. The ProcessRequest step is executed on the target
instance that is selected based on the request url.
Soon to come...
The webserver can be configured either by assigning a dynamically created EmbeddedWebapplicationConfiguration
to the constructor (file-less activation), or it can be read from a
file placed under the web application base path.
Currently the configuration supports the following settings:
- Path: the web application base path
- Port: the underlying socket server will listen on this port
- MaxWorkerThreadCount: limits the maximum number of worker threads that can be created (unused threads will be disregarded)
- FileSystemHandlerEnableDirectoryBrowsing: sets whether directory browsing is enabled
- RequestFilterModuleEnabled: sets if the incoming requests should be filtered based on the value of
- RequestFilterModuleAllowMask: a wildcardable mask that will filter out unwanted requests (eg.: 127.0.0.*)
A typical configuration file might look like:
The configuration file also supports commenting by applying the '#' prefix.