This module provides an output filter to rewrite HTML links in a
proxy situation, to ensure that links work for users outside the proxy.
It serves the same purpose as Apache's
For example, if a company has an application server at
appserver.example.com
that is only visible from within
the company's internal network, and a public webserver
www.example.com
, they may wish to provide a gateway to the
application server at http://www.example.com/appserver/
.
When the application server links to itself, those links need to be
rewritten to work through the gateway. <a href="http://appserver.example.com/foo/bar.html">foobar</a>
to
<a href="http://www.example.com/appserver/foo/bar.html">foobar</a>
making it accessible from outside.
mod_proxy_html was originally a third-party module for Apache HTTPD
2.0.x and later versions. It was donated to the ASF in 2011 along with
Internally, mod_proxy_html uses the HTMLParser module from the third-party libxml2 library. Unlike other libxml2 parsers, HTMLParser deals with HTML without requiring it to be well-formed XML. In particular, it understands about implied tags - like a closing </p> - and inserts them into the stream of SAX events used by mod_proxy_html. It also has explicit knowledge of W3C standards HTML 4 and XHTML 1, and can correct certain errors in them.
mod_proxy_html offers a range of options to control HTML parsing.
Error correction can be enabled (to your choice of HTML standard)
or disabled using
Internally, mod_proxy_html uses a smart HTML parser from the third-party libxml2 library. The parser uses Unicode (utf-8) internally. This makes it a somewhat-complex task to handle other encodings required to process many non-English-language websites. If this is not handled correctly, websites that display non-ASCII characters in encodings other than utf-8 (Unicode) will display incorrectly.
From the first release in 2003 to the donation to Apache in 2011,
internationalisation (i18n) support developed from near nothing to a
sophisticated framework capable of applying rules from HTTP, HTML and XML
to detect a document's encoding and handle it correctly. However,
this processing was common to mod_proxy_html and other modules using
libxml2, so it made sense to move it to a separate module rather than
maintain it in multiple places. That module is
The interaction of mod_proxy_html with mod_xml2enc is too complex to
be configured using regular filter configuration, including
<head>
sections.This turns on or off pre-parsing of metadata in HTML
<head>
sections.
If not required, turning ProxyHTMLMeta Off will give a small performance boost by skipping this parse step. However, it is sometimes necessary for internationalisation to work correctly.
<meta http-equiv="Content-Type" content="text/html;charset=foo">
or, in the case of an XHTML document, an XML declaration.
It is NOT required if the charset is declared in a real HTTP header
(which is always preferable) from the backend server, nor if the
document is utf-8 (unicode) or a subset such as ASCII.
You may also be able to dispense with it where documents use a
default declared using
The other effect of enabling <meta http-equiv=...>
declarations and convert
them to real HTTP headers, in keeping with the original purpose
of this form of the HTML <meta> element.
http-equiv
elements to HTTP headers, it is important that you
only enable it in cases where you trust the HTML content as much as you
trust the upstream server. If the HTML is controlled by bad actors, it
will be possible for them to inject arbitrary, possibly malicious, HTTP
headers into your server's responses.
A simple switch to enable or disable the proxy_html filter.
If
Note that the proxy_html filter will only act on HTML data (Content-Type text/html or application/xhtml+xml) and when the data are proxied. You can override this (at your own risk) by setting the PROXY_HTML_FORCE environment variable.
This is the key directive for rewriting HTML links. When parsing a document,
whenever a link target matches from-pattern, the matching
portion will be rewritten to to-pattern, as modified by any
flags supplied and by the
The optional third argument may define any of the following Flags. Flags are case-sensitive.
Ignore HTML links (pass through unchanged)
Ignore scripting events (pass through unchanged)
Pass embedded script and style sections through untouched.
Last-match. If this rule matches, no more rules are applied (note that this happens automatically for HTML links).
Opposite to L. Overrides the one-change-only default behaviour with HTML links.
Use Regular Expression matching-and-replace. from-pattern
is a regexp, and to-pattern
a replacement string that may be
based on the regexp. Regexp memory is supported: you can use brackets ()
in the from-pattern
and retrieve the matches with $1 to $9
in the to-pattern
.
If R is not set, it will use string-literal search-and-replace. The logic is starts-with in HTML links, but contains in scripting events and embedded script and style sections.
Use POSIX extended Regular Expressions. Only applicable with R.
Case-insensitive matching. Only applicable with R.
Disable regexp memory (for speed). Only applicable with R.
Line-based regexp matching. Only applicable with R.
Match at start only. This applies only to string matching (not regexps) and is irrelevant to HTML links.
Match at end only. This applies only to string matching (not regexps) and is irrelevant to HTML links.
Interpolate environment variables in to-pattern
.
A string of the form ${varname|default}
will be replaced by the
value of environment variable varname
. If that is unset, it
is replaced by default
. The |default
is optional.
NOTE: interpolation will only be enabled if
Interpolate environment variables in from-pattern
.
Patterns supported are as above.
NOTE: interpolation will only be enabled if
The optional fourth cond argument defines a condition
that will be evaluated per Request, provided
A cond is evaluated by the Expression Parser. In addition, the simpler syntax of conditions in mod_proxy_html 3.x for HTTPD 2.0 and 2.2 is also supported.
This enables per-request interpolation in
If interpolation is not enabled, all rules are pre-compiled at startup. With interpolation, they must be re-compiled for every request, which implies an extra processing overhead. It should therefore be enabled only when necessary.
In the first form, documents will be declared as HTML 4.01 or XHTML 1.0
according to the option selected. This option also determines whether
HTML or XHTML syntax is used for output. Note that the format of the
documents coming from the backend server is immaterial: the parser will
deal with it automatically. If the optional second argument is set to
Legacy
, documents will be declared "Transitional", an option that may
be necessary if you are proxying pre-1998 content or working with defective
authoring/publishing tools.
In the second form, it will insert your own FPI. The optional second argument determines whether SGML/HTML or XML/XHTML syntax will be used.
The third form declares documents as HTML 5.
The fourth form is new in HTTPD trunk and not yet available in released versions, and uses libxml2's HTML parser to detect the doctype.
If the first form is used, mod_proxy_html
will also clean up the HTML to the specified standard. It cannot
fix every error, but it will strip out bogus elements and attributes.
It will also optionally log other errors at
This directive takes one to three arguments as follows:
lowercase
Urls are rewritten to lowercasedospath
Backslashes in URLs are rewritten to forward slashes.reset
Unset any options set at a higher level in the configuration.Take care when using these. The fixes will correct certain authoring mistakes, but risk also erroneously fixing links that were correct to start with. Only use them if you know you have a broken backend server.
Set to Off
, HTML links are rewritten according to the
Set to On
, all scripting events (as determined by
You'll also need to take care over patterns matched, since the parser has no
knowledge of what is a URL within an embedded script or stylesheet.
In particular, extended matching of /
is likely to lead to
false matches.
This directive will cause mod_proxy_html to strip HTML comments. Note that this will also kill off any scripts or styles embedded in comments (a bogosity introduced in 1995/6 with Netscape 2 for the benefit of then-older browsers, but still in use today). It may also interfere with comment-based processors such as SSI or ESI: be sure to run any of those before mod_proxy_html in the filter chain if stripping comments!
In order to parse non-HTML content (stylesheets and scripts) embedded
in HTML documents,
The default is 8192, and will work well for almost all pages. However, if you know you're proxying pages containing stylesheets and/or scripts bigger than 8K (that is, for a single script or stylesheet, NOT in total), it will be more efficient to set a larger buffer size and avoid the need to resize the buffer dynamically during a request.
Specifies one or more attributes to treat as scripting events and
apply
Normally you'll set this globally. If you set
A default configuration is supplied in proxy-html.conf and defines the events in standard HTML 4 and XHTML 1. This can be extended to apply to URLs embedded in CSS stylesheet attributes by adding the style attribute to ProxyHTMLEvents, although this is not enabled in the shipped default.
Specifies elements that have URL attributes that should be rewritten
using standard
Normally you'll set this globally. If you set
A default configuration is supplied in proxy-html.conf and defines the HTML links for standard HTML 4 and XHTML 1.
This selects an encoding for mod_proxy_html output. It should not
normally be used, as any change from the default UTF-8
(Unicode - as used internally by libxml2) will impose an additional
processing overhead. The special token ProxyHTMLCharsetOut *
will generate output using the same encoding as the input.
Note that this relies on