Apache Module mod_policy

Summary

The HTTP protocol recommends that clients should be "liberal in
what they accept", and servers "strict with what they send". In some
cases it can be difficult to detect when a server or an application
has been misconfigured, is serving uncacheable content or is behaving
suboptimally, as an HTTP client might be compensating for the server.
These problems can potentially lead to excessive bandwidth
consumption, or a server outage under load.

The mod_policy module consists of a set of
filters that test servers for HTTP protocol compliance. These
tests allow the server administrator to log violations of, or
outright reject responses where certain defined conditions exist.

This could be used as a way to set minimum HTTP protocol compliance
criteria for a restful application. Alternatively, a reverse proxy or
cache could be configured to protect itself from misconfigured origin
servers or unexpectedly uncacheable content, or as a mechanism to
detect configuration mistakes within the server itself.

See also

The policy check will be ignored for the given URL space, even
if the filter is present.

log

The policy check will be executed, and if a violation is detected
a warning will be logged to the server error_log, and a
Warning header added to the response for the benefit of
the client.

enforce

The policy check will be executed, and if a violation is detected
an error will be logged to the server error_log, a
Warning header added to the response, and a 502
Bad Gateway will be returned to the client. Optional links to
explanatory documentation can be added to each error message,
detailing the origin of each policy.

It is also possible to selectively disable all policies for a
given URL space, should the need arise, using the
PolicyFilter directive.

Alternatively, the
PolicyEnvironment
directive can be used to specify an environment variable, which if
present, will cause the policies to be selectively downgraded or
bypassed.

The length of responses can be specified in one of three ways, by
specifying an explicit length in advance, using chunked encoding to set
the length, or by setting no length at all and terminating the request
when complete. The absence of a specific content length can affect the
cacheability of the response, and prevents the use of keepalive during
HTTP/1.0 requests. This policy enforces the presence of an explicit
content length on the response.

Less restrictive than the POLICY_LENGTH test, this policy enforces the
possibility that the response can be kept alive. If the response doesn't
have a protocol defined zero length, and the response isn't already an
error, and the response has neither a Content-Length or is declared
HTTP/1.1 and lacks Content-Encoding: chunked, then this response will be
rejected.

POLICY_VARY: Enforce the absence of certain headers within Vary headers

If the Vary header contains any of the headers specified, this policy
will reject the request. The typical case is the presence of the User-Agent
within Vary, which is likely to cause a denial of service condition to a
cache.

The ability for a cache to determine whether a cached entity can be
refreshed is dependent on whether a valid Etag and/or Last-Modified header
is present to revalidate against. The absence of both headers, or the
invalid syntax of a header will cause this policy to be rejected.

When conditional headers are present in the request, a server should
respond with a 304 Not Modified or 412 Precondition
Failed response where appropriate. A server may ignore conditional
headers, and this affects the efficiency of the HTTP caching mechanism.
This policy rejects requests where a conditional header is present, and
a 304 or 412 response code was expected, but a 2xx response was seen
instead.

Downgrade policies to logging only or ignored based on the presence
of an environment variable. If the given variable is present and equal
to the log-value, enforced policies will be logged instead. If the given
variable is present and equal to the ignore-value, all policies will
be ignored.

When logged or enforced, a response that lacks an explicit freshness
lifetime defined with max-age, s-maxage or an
Expires header, or where the explicit freshness lifetime is
smaller than the given value, will be rejected.

Example

# reject responses with a freshness lifetime shorter than a day
PolicyMaxage enforce 86400

Notice:This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.