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
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.
If a policy is violated, one of the following actions can be taken:
Warning
header added to the response for the benefit of
the client.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
Alternatively, the
The following policy filters are available:
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.Cache-Control: no-cache
Pragma: no-cache
Cache-Control: no-store
Cache-Control: private
s-maxage
is present but too small; ormax-age
is present but too small; orExpires
is present and invalid; orDate
is present and invalid; orExpires
minus Date is too small; ors-maxage
, maxage
, or
Expires
/Date
declared at allHTTP/1.1
HTTP/1.0
HTTP/0.9
A typical configuration protecting a server serving static content might be as follows:
Master switch to enable or disable policies for a given URL space.
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 should have been conditional but wasn't will be rejected.
Specify the URL of the documentation describing the conditional request policy, to appear within error messages.
When logged or enforced, a response that lacks an explicit
Content-Length
header will be rejected.
Specify the URL of the documentation describing the content length policy, to appear within error messages.
When logged or enforced, a response that lacks both an explicit
Content-Length
header and a Transfer-Encoding
of chunked
will be rejected.
Specify the URL of the documentation describing the keepalive policy, to appear within error messages.
When logged or enforced, a response that lacks a Content-Type
header, where the Content-Type
header is malformed, or where the
header does not match the given pattern or patterns will be rejected.
Specify the URL of the documentation describing the content type policy, to appear within error messages.
When logged or enforced, a response that contains a Vary
header which in turn contains one of the headers listed, will be
rejected.
Specify the URL of the documentation describing the vary policy, to appear within error messages.
When logged or enforced, a response that lacks either a valid
ETag
header or a Last-Modified
header, or where
either header is syntactically incorrect, will be rejected.
Specify the URL of the documentation describing the validation policy, to appear within error messages.
When logged or enforced, a response that defines itself uncacheable
using the Cache-Control
or Pragma
headers will
be rejected.
Specify the URL of the documentation describing the caching no-cache policy, to appear within error messages.
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.
Specify the URL of the documentation describing the caching minimum freshness lifetime policy, to appear within error messages.
When logged or enforced, a request with a version lower than specified will be rejected.
Specify the URL of the documentation describing the minimum request HTTP version policy, to appear within error messages.