I attached what I have in mind on how to solve this. It's basically what you suggested.
There's one thing I didn't know how to address and that is mod_proxy_html's ProxyHTMLExtended directive. It does suggest not to be turned on by default ( http://httpd.apache.org/docs/current/mod/mod_proxy_html.html#proxyhtmlextended) so I wouldn't put it into mod_xml2enc config creation. But then mod_proxy_html would have to cause mod_xml2enc to include CSS/JS as content type or we risk the two modules behaving inconsistently for non UTF-8 encoded documents. Personally, I wouldn't want to rely on the user to remember configuring ProxyHTMLExtended should always be paired with xml2AcceptContentType text/css and xml2AcceptContentType application/javascript. That's bound to cause problems. I don't know about the caveats of one module telling another module how to configure itself. Cheers, Thomas On Wed, May 29, 2013 at 8:20 PM, Nick Kew <n...@webthing.com> wrote: > > On 29 May 2013, at 14:28, Thomas Eckert wrote: > > > I saw the following > > > > /* only act if starts-with "text/" or contains "xml" */ > > if (strncmp(ctype, "text/", 5) && !strstr(ctype, "xml")) { > > ap_remove_output_filter(f); > > return ap_pass_brigade(f->next, bb) ; > > } > > You're right, that's a bug. > > I don't think your patch really works either: any hardwired rules are > going to be susceptible to similar issues. I guess what it needs is to > be user-configurable, perhaps with HTML and XHTML as defaults. > > -- > Nick Kew >
mod_xml2enc_ctype.patch
Description: Binary data
