From e7b60956a1ffe132adae613f5ba5963c551e17bc Mon Sep 17 00:00:00 2001 From: Emmanuel Lacour Date: Wed, 20 Aug 2008 10:06:20 +0000 Subject: [PATCH] Added faq.html. --- debian/docs | 1 + faq.html | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 83 insertions(+) create mode 100644 faq.html diff --git a/debian/docs b/debian/docs index 3a0c4da..37ac420 100644 --- a/debian/docs +++ b/debian/docs @@ -1,2 +1,3 @@ config.html guide.html +faq.html diff --git a/faq.html b/faq.html new file mode 100644 index 0000000..2139df2 --- /dev/null +++ b/faq.html @@ -0,0 +1,82 @@ + + + +mod_proxy_html + + +
+

mod_proxy_html: Frequently Asked Questions

+

This answers some of the most frequently asked questions +that aren't dealt with (or that people overlook) in the documentation +and the apachetutor tutorial. This was written for +Version 2, and most of the questions are moot in Version 3.

+

Questions

+
    +
  1. Can mod_proxy_html support (charset XYZ) as input?
    2. +
  2. Can mod_proxy_html support (charset XYZ) as output?
    3. +
  3. Why does mod_proxy_html mangle my Javascript?
    4. +
  4. Why doesn't mod_proxy_html rewrite urls in [some attribute]?
    5. +
+

Answers

+
+
Can mod_proxy_html support (charset XYZ) as input?
+

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.

+
+
Can mod_proxy_html support (charset XYZ) as output?
+

libxml2 uses utf-8 internally for everything. +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.

+
+
Why does mod_proxy_html mangle my Javascript?
+

It doesn't. Your javascript is simply too badly malformed, +and libxml2's error correction isn't what you expect! +Check it with a validator, +or with libxml2's xmllint --html +(which uses the same parser as mod_proxy_html). Here is +a fuller explanation.

+

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.

+
+
Why doesn't mod_proxy_html rewrite urls in [some attribute]?
+

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 +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.

+
+
+
+ -- 2.11.0