On 02/11/2014 06:03 PM, Nick Kew wrote:
On 6 Feb 2014, at 09:40, Ewald Dieterich wrote:
My wishlist:
* Make the configuration option as powerful as the compiled in fallback so that you can
configure eg. "contains xml". But how would you do that? Support regular
expressions?
Nice thought.
On 6 Feb 2014, at 09:40, Ewald Dieterich wrote:
> Thanks for the patch!
>
> On 02/05/2014 02:57 PM, Nick Kew wrote:
>>
>> The hesitation is because I've been wanting to review the
>> patch before committing, and round tuits are in woefully
>> short supply. So I'm attaching it here. I'll take
Doesn't
+else {
+/* default - only act if starts-with "text/" or contains "xml" */
+wanted = !strncmp(ctype, "text/", 5) || strstr(ctype, "xml");
+}
suffer from the same problem as the original code ? So if the user did not
give any "xml2Types" the default behaviour will h
Thanks for the patch!
On 02/05/2014 02:57 PM, Nick Kew wrote:
The hesitation is because I've been wanting to review the
patch before committing, and round tuits are in woefully
short supply. So I'm attaching it here. I'll take any feedback
from you or other users as a substitute for my own re
On 21 Jan 2014, at 07:14, Ewald Dieterich wrote:
> On 12/17/2013 12:47 PM, Nick Kew wrote:
>>
>> On 17 Dec 2013, at 10:32, Thomas Eckert wrote:
>>
>>> I've been over this with Nick before: mod_proxy_html uses mod_xml2enc to do
>>> the detection magic but mod_xml2enc fails to detect compressed
On 12/17/2013 12:47 PM, Nick Kew wrote:
On 17 Dec 2013, at 10:32, Thomas Eckert wrote:
I've been over this with Nick before: mod_proxy_html uses mod_xml2enc to do the detection
magic but mod_xml2enc fails to detect compressed content correctly. Hence a simple
"ProxyHTMLEnable" fails when con
Here is what I ended up with.
diff --git a/modules/filters/mod_deflate.c b/modules/filters/mod_deflate.c
index 605c158..fd3662a 100644
--- a/modules/filters/mod_deflate.c
+++ b/modules/filters/mod_deflate.c
@@ -450,6 +450,12 @@ static apr_status_t deflate_out_filter(ap_filter_t *f,
return
> IIRC the OP wants to decompress such contents and run them
> through mod_proxy_html. I don't think that works with any sane
> setup: running non-HTML content-types through proxy_html
> will always be an at-your-own-risk hack.
What I want is a (preferrably as simple as possible) method of config
On 5 Jan 2014, at 02:21, Nick Kew wrote:
> IIRC the OP wants to decompress such contents and run them through
> mod_proxy_html. I don't think that works with any sane setup: running
> non-HTML content-types through proxy_html will always be an at-your-own-risk
> hack.
I've believed for a whil
On 4 Jan 2014, at 13:36, Tim Bannister wrote:
> Gzip compressed content sometimes gets served with no declared encoding and a
> media type of, e.g., “application/x-gzip”. I reckon that's more common than
> serving it as application/octet-stream or with no Content-Type: declared.
>
> mod_deflat
On 4 Jan 2014, at 00:20, Nick Kew wrote:
> On 3 Jan 2014, at 13:39, Thomas Eckert wrote:
>
>> This does not solve the problem regarding .gz files however. They still
>> suffer from a double-compression.
…
> I'd say any such fix must lie in adding a compression-sniffing option
> to mod_deflate:
>
On 3 Jan 2014, at 13:39, Thomas Eckert wrote:
> This does not solve the problem regarding .gz files however. They still
> suffer from a double-compression.
AFAICT that's only when the backend sends compressed contents but
fails to declare the content-encoding?
> Using the above patch/configur
After applying
@@ -1569,10 +1579,13 @@ static void proxy_html_insert(request_rec *r)
proxy_html_conf *cfg;
cfg = ap_get_module_config(r->per_dir_config, &proxy_html_module);
if (cfg->enabled) {
-if (xml2enc_filter)
+ap_add_output_filter("INFLATE", NULL, r, r->connect
On 18 Dec 2013, at 14:47, Thomas Eckert wrote:
> No, yes and I tried but couldn't get it to work. Following your advice I went
> along the lines of
Yes, I'd be trying something like that. You can insert inflate (and deflate)
unconditionally, as they will check the headers themselves and remove
> Aha! Revisiting that, I see I still have an uncommitted patch to make
> content types to process configurable. I think that was an issue you
> originally raised? But compression is another issue.
Yep.
> Hmmm?
> If the backend sends compressed contents with no content-encoding,
doesn't that
Nick Kew wrote:
>
> Returning to:
>> SetOutputfilter INFLATE;xml2enc;proxy-html;DEFLATE
>
> AFAICS the only thing that's missing is the nonessential step 4 above.
Which can be avoided with a setenvif Request_URI "\.gz$" no-gzip
Regards
Rüdiger
On 17 Dec 2013, at 10:32, Thomas Eckert wrote:
> I've been over this with Nick before: mod_proxy_html uses mod_xml2enc to do
> the detection magic but mod_xml2enc fails to detect compressed content
> correctly. Hence a simple "ProxyHTMLEnable" fails when content compression is
> in place.
Aha
I've been over this with Nick before: mod_proxy_html uses mod_xml2enc to do
the detection magic but mod_xml2enc fails to detect compressed content
correctly. Hence a simple "ProxyHTMLEnable" fails when content compression
is in place.
To work around this without dropping support for content compre
18 matches
Mail list logo
