mod_proxy_html: Technical Guide

mod_proxy_html From Version 2.4 (Sept 2004). -Updates in Version 3 (Dec. 2006) are highlighted.

mod_proxy_html Version 3.1 (April 2009).

URL Rewriting @@ -65,25 +64,25 @@ and scripting events, where it is clearly irrelevant.

HTML Links

HTML links are those attributes defined by the HTML 4 and XHTML 1 DTDs as of type %URI. For example, the href -attribute of the a element. For a full list, see the -declaration of linked_elts in pstartElement. +attribute of the a element. Rules are applicable provided the h flag is not set. -From Version 3, the definition of links to use is -delegated to the system administrator via the ProxyHTMLLinks -directive.

ProxyHTMLLinks

proxy_html.conf

An HTML link always contains exactly one URL. So whenever mod_proxy_html finds a matching ProxyHTMLURLMap rule, it will apply the -transformation once and stop processing the attribute. This +transformation once and stop processing the attribute. This can be overridden by the l flag, which causes processing -a URL to continue after a rewrite.

Scripting Events

Scripting events are the contents of event attributes as defined in the -HTML4 and XHTML1 DTDs; for example onclick. For a full list, -see the declaration of events in pstartElement. +HTML4 and XHTML1 DTDs; for example onclick. Rules are applicable provided the e flag is not set. -From Version 3, the definition of events to use is +From Version 3, the definition of events to use is delegated to the system administrator via the ProxyHTMLEvents -directive.

proxy_html.conf

A scripting event may contain more than one URL, and will contain other text. So when ProxyHTMLExtended is On, all applicable rules will be applied in order until and unless a rule with the L flag @@ -128,7 +127,7 @@ apply the appropriate rules in generating output. HTML saves a few bytes.

If you declare a custom DTD, you should specify whether to generate HTML or XHTML syntax in the output. This affects empty elements: HTML <br> vs XHTML <br />.

If you select standard HTML or XHTML, mod_proxy_html 3 will +

If you select standard HTML or XHTML, mod_proxy_html 3 will perform some additional fixups of bogus markup. If you don't want this, you can enter a standard DTD using the nonstandard form of ProxyHTMLDTD, which will then be treated as unknown @@ -137,16 +136,14 @@ you can enter a standard DTD using the nonstandard form of

The parser uses UTF-8 (Unicode) internally, and mod_proxy_html prior to version 3 always generates output as UTF-8. This is supported by all general-purpose web software, and supports more -character sets and languages than any other charset. -Version 3 supports, but does not recommend different outputs, using -the ProxyHTMLCharsetOut directive.

The character encoding should be declared in HTTP: for example
Content-Type: text/html; charset=latin1
mod_proxy_html has always supported this in its input, and ensured this happens in output. But prior to version 2, it did not fully support detection (sniffing) the charset when a backend fails to set the HTTP Header.

From version 2.0, mod_proxy_html will detect the encoding of its input +

From version 2, mod_proxy_html will detect the encoding of its input as follows:

The HTTP headers, where available, always take precedence over other @@ -158,27 +155,22 @@ information.

<meta http-equiv="Content-Type" ...>

In the absence of any of the above indications, the HTML-over-HTTP default -encoding ISO-8859-1 or the -ProxyHTMLCharsetDefault value is assumed.

ISO-8859-1

The parser is set to ignore invalid characters, so a malformed input stream will generate glitches (unexpected characters) rather than risk aborting a parse altogether.

In version 3.0, this remains the default, but -internationalisation support is further improved, and is no longer -limited to the encodings supported by libxml2:

The ProxyHTMLCharsetAlias directive enables server -administrators to support additional encodings by aliasing them to -something supported by libxml2.
When a charset that is neither directly supported nor aliased is -encountered, mod_proxy_html 3 will attempt to support it using Apache/APR's -charset conversion support in apr_xlate, which on most platforms -is a wrapper for the leading conversion utility iconv. -Because of undocumented behaviour of libxml2, this may cause problems -when charset is specified in an HTML META element. This -feature is therefore only enabled when ProxyHTMLMeta is On.

From Version 3.1 the above is delegated to +mod_xml2enc, which also expands charset support +and enables you to:

Handle any character set supported by iconv on your system, in addition +to those supported by libxml2.
Alias an unsupported charset to a supported one: for example nonstandard +Windows codepages to ISO equivalents.
Override the ISO-8859-1 Default encoding.
Convert output to your choice of charset (at an additional processing cost).

meta http-equiv support

The HTML meta element includes a form @@ -227,4 +219,12 @@ and after, and possibly in the middle of, a page. To work around this, set the force-response-1.0 environment variable in httpd.conf. For example,
BrowserMatch MSIE force-response-1.0

mod_proxy_html: Technical Guide

Contents

HTML Links

Scripting Events

meta http-equiv support