That depends entirely on libxml2. mod_proxy_html supports -charset detection, but does not itself support any charsets. -It works by passing the charset detected to libxml2 when it sets -up the parser.
-This means that mod_proxy_html inherits its charset support -from libxml2, and will always support exactly the same -charsets available in the version of libxml2 you have installed. -So bug the libxml2 folks, not us!
-In Version 3, charset support is much expanded provided
-ProxyHTMLMeta is enabled, and any charset can be supported
-by aliasing it with ProxyHTMLCharsetAlias.
In version 2, that depends entirely on libxml2, and your charset +is supported if and only if libxml2 supports it.
+In Version 3.1, charset support is much expanded provided
+mod_xml2enc is enabled. It is normally
+sufficient just to load mod_xml2enc: it will be configured automatically
+if you configure mod_proxy_html using ProxyHTMLEnable.
+In a few cases, you may need to customise charset support further using
+mod_xml2enc's directives.
Note that some servers send inconsistent and even conflicting charset
+information, and may generate unexpected results. Setting
+ProxyHTMLMeta On may help resolve such cases, and will
+help diagnose problems with extra debug information in the error log.
libxml2 uses utf-8 internally for everything.
@@ -40,8 +41,9 @@ Generating output with another charset is therefore an additional
overhead, and the decision was taken to exclude any such capability
from mod_proxy_html. There is an easy workaround: you can transcode
the output using another filter, such as mod_charset_lite.
Version 3 supports output transformation to other
-charsets using ProxyHTMLCharsetOut.
mod_proxy_html 3 supports output transformation to other
+charsets using ProxyHTMLCharsetOut. This requires
+mod_xml2enc to be loaded.
It doesn't. Your javascript is simply too badly malformed, @@ -53,22 +55,37 @@ or with libxml2's xmllint --html
The best fix for this is to remove the javascript from your markup, and import it from a separate .js file. If you have an irredeemably broken publishing system, you may have to upgrade to -mod_publisher or resort to the -non-markup-aware mod_line_edit.
+mod_publisher or resort to a markup-blind +filter such as mod_line_edit, +mod_substitute or mod_sed.mod_proxy_html is based on W3C HTML 4.01 and XHTML 1.0 (which are -identical in terms of elements and attributes). It supports all links +
mod_proxy_html versions 1 and 2 are based on W3C HTML 4.01 and +XHTML 1.0 (which are identical in terms of elements and attributes). +It supports all links defined in W3C HTML, even those that have been deprecated since 1997. But it does NOT support proprietary pseudo-HTML "extensions" that have never been part of any published HTML standard. Of course, it's trivial to add them to the source.
This has been the most commonly requested feature since mod_proxy_html 2.0 -was released in 2004. It cannot reasonably be satisfied, because everyone's -pet "extensions" are different. Version 3 deals with this -by taking all HTML knowledge out of the code and loading it from httpd.conf -instead, so admins can meet their own needs without recompiling.
+was released in 2004. Since everyone's requirements are different, it +could not reasonably be satisfied with a simple one-size-fits-all fix. +Version 3 of mod_proxy_html delegates the definition of HTML links to +the system administrator, via the configuration file. +A sample file proxy_html.conf is provided, and defines +standard W3C HTML/XHTML. Note that you MUST include this (or equivalent) +into your configuration, or no links will be rewritten! If you need to +support nonstandard HTML variants, follow the instructions in +proxy_html.conf.