Determining which steps are active during the request-response cycle
This note describes how the server is modularized and how it can be configured to behave differently by enabling and disabling individual modules.
The HTTP request-response cycle can be configured to include or exclude optional processing steps. This level of configuration is like flipping a series of master switches. Disabled modules are completely ignored: their associated configuration section is not validated and their processing handler is bypassed.
This design can be beneficial during development and production, allowing the devops staff to quickly reconfigure the server to test features and troubleshoot problems.
Most of the server's optional modules are preconfigured by default to be disabled; you must enable them explicitly before their handlers will have any effect.
The optional modules perform a variety of tasks which can conceptually be grouped into: 1) security, 2) negotiation, 3) caching, 4) processing, and 5) monitoring modules.
ip-access module can block blacklisted IP addresses from making requests to the server.
forbidden module prevents access to files paths that are in the public document area.
rbac module is a Role Based Access Control protocol allowing granular permissions to be set on resource paths.
cross-origin module is used to configure the CORS protocol.
accept-language module handles content language negotiation.
content-encoding module saves outgoing bandwidth by compressing responses.
etag module allows browsers to handle caching with fewer false positives.
cache-control module defines the browser caching instructions to be sent with each request.
user-agent module can recognize crawlers and selectively disable path access and/or speculative push notifications.
resource-masks module converts SEO-friendly URLs and microservice API calls into canonical server paths.
push-priority module configures the rules to use for requests that are candidates for HTTP/2 speculative push protocol.
information-headers module provides contextual information about response status codes.
custom-errors module displays error messages in a natural language suitable to the website's readers, and with CSS to match the website's styling rules.
counters module provides real-time access to basic server usage data.
policies module is used to configure the security and error logging policies that browsers should enforce on
Modules are configured by adding entries to the
modules section. Each entry should be on a separate line, and contain only the name of the module and the keyword
off. Modules names that are not explicitly configured, are off by default.
modules configuration section may appear in either the
server section or a
host section. When values occur in both the
host sections, they are merged according to the standard rules defined for the
|named-module-entry||::=||module-name SP ('on' | 'off') CR|
|modules-section||::=||'modules' SP LEFT-CURLY-BRACKET CR|
Example 1: Standard modules only
Example 2: Explicitly turned off
This example is equivalent to Example 1, but is more explicit.
Key points to remember:
- The modules configuration is a master switch, and should always be checked when diagnosing why the server is not responding as expected.
- Two common mistakes are:
- having the module turned on, but forgetting to add its configuration rules;
- having a module's section correctly configured, but neglecting to turn the module on.