|The Apache HTTP Server Reference Manual
by Apache Software Foundation
Paperback (6"x9"), 862 pages
RRP £19.95 ($29.95)
Interoperability problems have led to the introduction of mechanisms to modify the way Apache behaves when talking to particular clients. To make these mechanisms as flexible as possible, they are invoked by defining environment variables, typically with BrowserMatch, though SetEnv and PassEnv could also be used, for example.
This forces the request to be treated as a HTTP/1.0 request even if it was in a later dialect.
If you have the DEFLATE filter activated, this environment variable will ignore the accept-encoding setting of your browser and will send compressed output unconditionally.
This causes any Vary fields to be removed from the response header before it is sent back to the client. Some clients don’t interpret this field correctly; setting this variable can work around this problem. Setting this variable also implies force-response-1.0.
This forces an HTTP/1.0 response to clients making an HTTP/1.0 request. It was originally implemented as a result of a problem with AOL’s proxies. Some HTTP/1.0 clients may not behave correctly when given an HTTP/1.1 response, and this can be used to interoperate with them.
When set to a value of "1", this variable disables the DEFLATE output filter provided by mod_deflate for content-types other than text/html. If you’d rather use statically compressed files, mod_negotiation evaluates the variable as well (not only for gzip, but for all encodings that differ from "identity").
Available in versions 2.2.12 and later
This influences mod_negotiation’s behaviour. If it contains a language tag (such as en, ja or x-klingon), mod_negotiation tries to deliver a variant with that language. If there’s no such variant, the normal negotiation (p. 1423) process applies.
This forces the server to be more careful when sending a redirect to the client. This is typically used when a client has a known problem handling redirects. This was originally implemented as a result of a problem with Microsoft’s WebFolders software which has a problem handling redirects on directory resources via DAV methods.
Available in versions after 2.0.54
When Apache issues a redirect in response to a client request, the response includes some actual text to be displayed in case the client can’t (or doesn’t) automatically follow the redirection. Apache ordinarily labels this text according to the character set which it uses, which is ISO-8859-1.
However, if the redirection is to a page that uses a different character set, some broken browser versions will try to use the character set from the redirection text rather than the actual page. This can result in Greek, for instance, being incorrectly rendered.
Setting this environment variable causes Apache to omit the character set for the redirection text, and these broken browsers will then correctly use that of the destination page.
Sending error pages without a specified character set may allow a cross-site-scripting attack for existing browsers (MSIE) which do not follow the HTTP/1.1 specification and attempt to "guess" the character set from the content. Such browsers can be easily fooled into using the UTF-7 character set, and UTF-7 content from input data (such as the request-URI) will not be escaped by the usual escaping mechanisms designed to prevent cross-site-scripting attacks.
19.3.12 force-proxy-request-1.0, proxy-nokeepalive, proxy-sendchunked, proxy-sendcl, proxy-chain-auth, proxy-interim-response, proxy-initial-not-pooled
|ISBN 9781906966034||The Apache HTTP Server Reference Manual||See the print edition|