On Wed, Dec 20, 2023 at 10:58 AM Joe Orton wrote:
>
> On Wed, Dec 20, 2023 at 04:24:32PM +0100, Ruediger Pluem wrote:
> > On 12/20/23 4:08 PM, Yann Ylavic wrote:
> > > On Wed, Dec 20, 2023 at 2:40 PM Joe Orton wrote:
> > >> https://github.com/apache/httpd/pull/400
> > >
> > > Thanks, looks good
On Wed, Dec 20, 2023 at 4:57 PM Joe Orton wrote:
>
> On Wed, Dec 20, 2023 at 04:24:32PM +0100, Ruediger Pluem wrote:
> > On 12/20/23 4:08 PM, Yann Ylavic wrote:
> > > On Wed, Dec 20, 2023 at 2:40 PM Joe Orton wrote:
> > >> https://github.com/apache/httpd/pull/400
> > >
> > > Thanks, looks good
On Wed, Dec 20, 2023 at 10:43 AM Joe Orton wrote:
>
> In the repro case you posted, only one brigade is passed by the handler,
> with that I saw the "delayed last chunk" behaviour but not the Zlib
> double-deinit error log. I think the Zlib error would only be triggered
> by passing a second
On Wed, Dec 20, 2023 at 4:45 PM Yann Ylavic wrote:
>
> On Wed, Dec 20, 2023 at 4:18 PM Eric Norris wrote:
> >
> > On Wed, Dec 20, 2023 at 10:09 AM Yann Ylavic wrote:
> > >
> > > So I think what the POC or mod_php should be doing is [FLUSH EOS] or
> > > something might not work in the chain
On Wed, Dec 20, 2023 at 04:24:32PM +0100, Ruediger Pluem wrote:
> On 12/20/23 4:08 PM, Yann Ylavic wrote:
> > On Wed, Dec 20, 2023 at 2:40 PM Joe Orton wrote:
> >> https://github.com/apache/httpd/pull/400
> >
> > Thanks, looks good to me.
>
> +1
Thanks a lot for the quick reviews. Merged in
On Wed, Dec 20, 2023 at 4:18 PM Eric Norris wrote:
>
> On Wed, Dec 20, 2023 at 10:09 AM Yann Ylavic wrote:
> >
> > So I think what the POC or mod_php should be doing is [FLUSH EOS] or
> > something might not work in the chain sooner or later?
>
> I believe that is what the POC was doing here
>
On Wed, Dec 20, 2023 at 10:07:19AM -0500, Eric Norris via dev wrote:
> Thanks Joe, and no need to apologize, that's totally understandable.
>
> I also appreciate you taking a look at the chunk filter behavior as that
> was actually going to be the next patch I proposed. I had written it here:
>
On 12/20/23 4:08 PM, Yann Ylavic wrote:
> On Wed, Dec 20, 2023 at 2:40 PM Joe Orton wrote:
>>
>> I was surprised this made a difference to the behaviour on the wire. It
>> seems like the chunk filter has suboptimal behaviour here. If you take
>> an output brigade like either:
>>
>> a) [HEAP
On Wed, Dec 20, 2023 at 10:09 AM Yann Ylavic wrote:
>
> On Wed, Dec 20, 2023 at 2:40 PM Joe Orton wrote:
> >
> > I was surprised this made a difference to the behaviour on the wire. It
> > seems like the chunk filter has suboptimal behaviour here. If you take
> > an output brigade like either:
>
On Wed, Dec 20, 2023 at 2:40 PM Joe Orton wrote:
>
> I was surprised this made a difference to the behaviour on the wire. It
> seems like the chunk filter has suboptimal behaviour here. If you take
> an output brigade like either:
>
> a) [HEAP FLUSH EOS]
> b) [HEAP FLUSH EOS FLUSH]
>
> in both
Thanks Joe, and no need to apologize, that's totally understandable.
I also appreciate you taking a look at the chunk filter behavior as that
was actually going to be the next patch I proposed. I had written it here:
On Mon, Oct 30, 2023 at 10:47:44AM -0400, Eric Norris via dev wrote:
> Hello again,
>
> I'd like to politely bump this message to see if anyone would mind
> taking a look at this patch, either here or on GitHub.
Apologies, I got quite distracted by the "rapid reset" security stuff
earlier in
Hello again,
I'd like to politely bump this message to see if anyone would mind
taking a look at this patch, either here or on GitHub.
Eric Norris
Etsy
On Mon, Oct 9, 2023 at 2:50 PM Eric Norris wrote:
>
> Hello all,
>
> I've submitted a pull request on GitHub here:
>
On Sun, Dec 23, 2018 at 02:32:30PM +0100, Yann Ylavic wrote:
> Thanks Stefan, I didn't notice before in your proposed patch, but it
> looks like uint64_t casts should be apr_uint64_t too.
>
> Regards,
> Yann.
Right. I went ahead and fixed it in r1849630.
Thanks,
Stefan
On Sun, Dec 23, 2018 at 10:33 AM Stefan Sperling wrote:
>
> On Wed, Dec 19, 2018 at 07:03:39PM +0100, Stefan Sperling wrote:
> > On Wed, Dec 19, 2018 at 02:58:28PM +0100, Yann Ylavic wrote:
> > > On Wed, Dec 19, 2018 at 9:53 AM Stefan Sperling wrote:
> > > >
> > > > On Tue, Dec 18, 2018 at
On Wed, Dec 19, 2018 at 07:03:39PM +0100, Stefan Sperling wrote:
> On Wed, Dec 19, 2018 at 02:58:28PM +0100, Yann Ylavic wrote:
> > On Wed, Dec 19, 2018 at 9:53 AM Stefan Sperling wrote:
> > >
> > > On Tue, Dec 18, 2018 at 12:29:18AM +0100, Yann Ylavic wrote:
> > > > But yes, upcast is better,
On Wed, Dec 19, 2018 at 02:58:28PM +0100, Yann Ylavic wrote:
> On Wed, Dec 19, 2018 at 9:53 AM Stefan Sperling wrote:
> >
> > On Tue, Dec 18, 2018 at 12:29:18AM +0100, Yann Ylavic wrote:
> > > But yes, upcast is better, while at it I'd go for uint64_t...
> >
> > Like this?
>
> I think
On Wed, Dec 19, 2018 at 9:53 AM Stefan Sperling wrote:
>
> On Tue, Dec 18, 2018 at 12:29:18AM +0100, Yann Ylavic wrote:
> > But yes, upcast is better, while at it I'd go for uint64_t...
>
> Like this?
I think APR_UINT64_T_FMT/apr_uint64_t would be more portable ;)
Thanks for taking care of this
On Tue, Dec 18, 2018 at 12:29:18AM +0100, Yann Ylavic wrote:
> But yes, upcast is better, while at it I'd go for uint64_t...
Like this?
I've noticed that the same problem seems to exist in some other modules.
I'll send separate patches for those once this patch has settled.
Index:
On Mon, Dec 17, 2018 at 5:40 PM William A Rowe Jr wrote:
>
> On Sun, Dec 16, 2018 at 7:27 AM Yann Ylavic wrote:
>>
>>
>> Since it's logging only, it may be easier to cast to (long) each
>> total_in/out though.
>
> Downcast? Why not upcast to apr_off_t and use the _FMT macro as first
>
On Sun, Dec 16, 2018 at 7:27 AM Yann Ylavic wrote:
>
> Since it's logging only, it may be easier to cast to (long) each
> total_in/out though.
>
Downcast? Why not upcast to apr_off_t and use the _FMT macro as first
suggested?
On Sun, Dec 16, 2018 at 2:21 PM Yann Ylavic wrote:
>
> On Sun, Dec 16, 2018 at 2:14 PM Stefan Sperling wrote:
> >
> > The file /usr/include/zlib.h I have on OpenBSD -current has this:
> >
> > typedef struct z_stream_s {
> > [...]
> > z_off_t total_in; /* total nb of input bytes read so
On Sun, Dec 16, 2018 at 2:14 PM Stefan Sperling wrote:
>
> The file /usr/include/zlib.h I have on OpenBSD -current has this:
>
> typedef struct z_stream_s {
> [...]
> z_off_t total_in; /* total nb of input bytes read so far */
> [...]
> z_off_t total_out; /* total nb of bytes
On Sun, Dec 16, 2018 at 02:03:45PM +0100, Yann Ylavic wrote:
> On Sun, Dec 16, 2018 at 1:28 PM Stefan Sperling wrote:
> >
> > mod_deflates hard-codes some off_t format directives to "%ld".
> > It seems to me this code should use the macro provided by APR instead.
> >
> > Looking for another pair
On Sun, Dec 16, 2018 at 1:28 PM Stefan Sperling wrote:
>
> mod_deflates hard-codes some off_t format directives to "%ld".
> It seems to me this code should use the macro provided by APR instead.
>
> Looking for another pair of eyes. Does this patch look good to commit?
It seems that zlib defines
Sent the wrong one.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
--- mod_deflate.c~ 2005-11-10 10:20:05.0 -0500
+++ mod_deflate.c 2006-03-28 14:07:32.0 -0500
@@ -401,7 +401,8 @@
apr_bucket *b;
apr_size_t len;
int done = 0;
On Wed, Jun 09, 2004 at 05:23:38PM -0400, Allan Edwards wrote:
Running ProxyPass with mod_deflate results in
an extraneous 20 bytes being tacked onto 304
responses from the backend.
The problem is that mod_deflate doesn't handle
the zero byte body, adds the gzip header and
tries to
On Wed, 9 Jun 2004, Allan Edwards wrote:
Running ProxyPass with mod_deflate results in
an extraneous 20 bytes being tacked onto 304
responses from the backend.
The problem is that mod_deflate doesn't handle
the zero byte body, adds the gzip header and
tries to compress 0 bytes.
This
Joe Orton wrote:
Wouldn't it be simpler to just check for a brigade containing just EOS
and do nothing for that case in the first place?
Yes I had considered that. The initial patch covered some pathological
cases but after having looked over the code some more I think the simpler
more efficient
On Wed, 9 Jun 2004, Allan Edwards wrote:
+}
+else {
+/* this was a zero length response, remove gzip header bucket then
pass down the EOS */
+APR_BUCKET_REMOVE(APR_BRIGADE_FIRST(ctx-bb));
+APR_BUCKET_REMOVE(e);
+
Cliff Woolley wrote:
I haven't looked at the entire context of this, but if you remove a bucket
(brigade_first(ctx-bb) from a brigade without deleting it and without
having any extra pointers to it, you'll leak memory.
Thanks for catching that! I'll replace APR_BUCKET_REMOVE with
a call to
On Wed, 9 Jun 2004, Allan Edwards wrote:
Also just realized I need to add a call to deflateEnd().
Oh right, that too. :-)
e is on the brigade passed into deflate_out_filter and the gzip
header bucket is in ctx-bb so that is not a problem.
Ah, yeah, that would make sense. Cool.
Ok, let be pragmatic. Did Apache HTTP developpers agree that
compression should be added in Apache 2.0 by incorporating mod_gzip
comp code in Apache 2.0 ?
mod_deflate is already there and it uses an external zlib library, so
I'm confused why we should also provide mod_gzip and/or its
William A. Rowe, Jr. wrote:
At 09:58 AM 11/21/2002, Henri Gomez wrote:
So what about for 2.0.45 dev ?
My prediction about interest in such a switch was independent of
timeframe. I doubt that such a switch will ever happen.
2.0.44 won't be the last 2.0 release isn't it ?
No... 2.0.45
--On Friday, November 22, 2002 12:03 PM +0100 Henri Gomez
[EMAIL PROTECTED] wrote:
So we should use a copy of mod_gzip compression code in Apache 2.0.
Also as someone involved in mod_jk/jk2, I'll need gzip
compress/uncompress support in Apache 2.0 for a new ajp protocol
I'm working on, so
I also refer you to the discussion thread regarding the
original inclusion of mod_deflate which contains some
'advice' posted to the Apache forum from Dr. Mark Adler
( one of the original authors of all this GZIP/ZLIB LZ77
code ).
He suggested that compiling your OWN version of GZIP/ZLIB
was
At 09:58 AM 11/21/2002, Henri Gomez wrote:
So what about for 2.0.45 dev ?
My prediction about interest in such a switch was independent of
timeframe. I doubt that such a switch will ever happen.
2.0.44 won't be the last 2.0 release isn't it ?
No... 2.0.45 will be compatible with 2.0.44
Bill Stoddard wrote:
Pie is rarely free at a truck stop.
At least none that you would want to dip your fingers into
And in fine what about mod_deflate to be added by default in
Apache 2.0.44 ?
And if so should we use the mod_gzip compression functions instead of
depending on zlib ?
Henri Gomez [EMAIL PROTECTED] writes:
And in fine what about mod_deflate to be added by default in
Apache 2.0.44 ?
And if so should we use the mod_gzip compression functions instead of
depending on zlib ?
I would be shocked if any significant subset of the people who have to
support this
Jeff Trawick wrote:
Henri Gomez [EMAIL PROTECTED] writes:
And in fine what about mod_deflate to be added by default in
Apache 2.0.44 ?
And if so should we use the mod_gzip compression functions instead of
depending on zlib ?
I would be shocked if any significant subset of the people who
Henri Gomez [EMAIL PROTECTED] writes:
Jeff Trawick wrote:
Henri Gomez [EMAIL PROTECTED] writes:
And in fine what about mod_deflate to be added by default in
Apache 2.0.44 ?
And if so should we use the mod_gzip compression functions instead of
depending on zlib ?
I would be shocked if
of Apache which is not 100% HTTP
compliant?
Regards,
Peter
-Original Message-
From: Henri Gomez [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 2:55 AM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] mod_deflate extensions
Bill Stoddard wrote:
Pie is rarely free at a truck
So what about for 2.0.45 dev ?
My prediction about interest in such a switch was independent of
timeframe. I doubt that such a switch will ever happen.
2.0.44 won't be the last 2.0 release isn't it ?
What do you means ?
- Put zlib full source tree in Apache 2.0 tree and make
a static
Peter J. Cranstone wrote:
And in fine what about mod_deflate to be added by default in
Apache 2.0.44 ?
Here's a reason for this. Content encoding and the ability to send
compressed data is part of the HTTP standard and if Apache 2.x is really
HTTP compliant then it should support it.
The
Henri Gomez wrote...
- Put part of zlib code in Apache 2.0 source ?
Jeff Trawick wrote...
that is what I suspect to be the safest, easiest-to-understand way...
the build would work like on Windows, where the project file for
mod_deflate pulls in the right parts when building
Kris Verbeeck wrote:
Henri Gomez wrote:
BTW, I'll next check if mod_deflate works in conjunction with
mod_jk/mod_jk2 (where I'm commiter).
It works, at least for me.
Good news :)
And it works for any JSP/Servlet contents send back from the servlet
engine to the browser ?
I'll be happy
William A. Rowe, Jr. wrote:
At 02:42 AM 11/11/2002, Henri Gomez wrote:
Justin Erenkrantz wrote:
--On Friday, November 8, 2002 5:52 PM +0100 Henri Gomez
[EMAIL PROTECTED] wrote:
Some questions about mod_deflate :
1) Why this module is not enabled by default built ?
compression should
Henri Gomez [EMAIL PROTECTED] writes:
When you drop the network bandwith by 30 to 70% factor, you make your IT
managers happy since they save money and you make end-users very happy
since they feel you application is faster.
when you drop the web server throughput by x% factor you may make
Title: RE: [PATCH] mod_deflate extensions
I agree that mod_deflate should be part of the distribution.
Are there any issues with apache including zlib in the distribution?
Best regards,
Juan C. Rivera
Citrix Systems, Inc.
-Original Message-
From: Jeff Trawick [mailto:[EMAIL
Jeff Trawick wrote:
Henri Gomez [EMAIL PROTECTED] writes:
When you drop the network bandwith by 30 to 70% factor, you make your IT
managers happy since they save money and you make end-users very happy
since they feel you application is faster.
when you drop the web server throughput by x%
Kris Verbeeck wrote:
Henri Gomez wrote:
BTW, I'll next check if mod_deflate works in conjunction with
mod_jk/mod_jk2 (where I'm commiter).
It works, at least for me.
Good news :)
And it works for any JSP/Servlet contents send back from the servlet
engine to the browser ?
I'll be happy
something like this in httpd.conf:
JkWorkersFile /tomcat/conf/workers.properties
JkExtractSSL On
JkHTTPSIndicator HTTPS
JkSESSIONIndicator SSL_SESSION_ID
JkCIPHERIndicator SSL_CIPHER
JkCERTSIndicator SSL_CLIENT_CERT
PS, there is no need to set Jk SSL env since there
are set
Peter J. Cranstone [EMAIL PROTECTED] writes:
Since when does web server throughput drop by x% factor using
mod_deflate?
I don't think you need me to explain the why or the when to you.
We went through this debate with mod_gzip and it doesn't hold much
water. Server boxes are cheap and
Peter J. Cranstone wrote...
Since when does web server throughput drop by x% factor using
mod_deflate?
Jeff Trawick wrote...
I don't think you need me to explain the why or the when to you.
Think again.
Exactly what scenario are you assuming is supposed to
be so 'obvious' that it
Pie is rarely free at a truck stop.
At least none that you would want to dip your fingers into
B
Henri Gomez wrote:
BTW, I'll next check if mod_deflate works in conjunction with
mod_jk/mod_jk2 (where I'm commiter).
It works, at least for me.
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Dietz, Phil E. wrote:
On a side note...
I think there should be a SetNote command so admins can tweak module settings through (instead of SetEnv like below)...
Using SetEnv exposes the result to cgi applications...which is not always a good thing.
I followed the current mod_deflate behaviour
Justin Erenkrantz wrote:
--On Friday, November 8, 2002 5:52 PM +0100 Henri Gomez
[EMAIL PROTECTED] wrote:
Some questions about mod_deflate :
1) Why this module is not enabled by default built ?
compression should be on to meet HTTP recommandations ?
No, that's not part of the HTTP
At 02:42 AM 11/11/2002, Henri Gomez wrote:
Justin Erenkrantz wrote:
--On Friday, November 8, 2002 5:52 PM +0100 Henri Gomez [EMAIL PROTECTED] wrote:
Some questions about mod_deflate :
1) Why this module is not enabled by default built ?
compression should be on to meet HTTP
--On Friday, November 8, 2002 5:52 PM +0100 Henri Gomez
[EMAIL PROTECTED] wrote:
Some questions about mod_deflate :
1) Why this module is not enabled by default built ?
compression should be on to meet HTTP recommandations ?
No, that's not part of the HTTP specification per se.
2)
On a side note...
I think there should be a SetNote command so admins can tweak module settings through
(instead of SetEnv like below)...
Using SetEnv exposes the result to cgi applications...which is not always a good thing.
-Original Message-
From: Henri Gomez [SMTP:[EMAIL
Henri Gomez [EMAIL PROTECTED] writes:
Some questions about mod_deflate :
1) Why this module is not enabled by default built ?
compression should be on to meet HTTP recommandations ?
asking for trouble w.r.t. the build unless we package the zlib code
ourselves and built it ourself in
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
The follow patch will allow binds to a static zlib, but it's not entirely portable.
This isn't what you were going for exactly, but it works for me on
HP-UX, Linux, AIX, and Solaris:
apxs -c mod_deflate.c zlib1.c zlib2.c zlib3.c etc.
(replace
At 09:23 AM 10/17/2002, Jeff Trawick wrote:
Another little note:
A user of my mod_deflate build encountered a problem loading
mod_deflate alongside another module loaded another library which also
had a symbol called crc32 and the wrong one was used. So to my apxs
command I add
Thanks. There was a fix committed for this a couple of weeks
ago, so 2.0.41 will have the right logic.
Brian
Spinka, Kristofer wrote:
Description:
The Apache environment variable gzip-only-text/html was designed to
allow control over whether non-text/html content will be
On Sun, 17 Feb 2002, Graham Leggett wrote:
Igor Sysoev wrote:
The main problem is proxies, especially Squid (~70% of all proxies)
Proxies can store compressed response and return it to browser
that does not understand gzipped content.
Is this verified behavior? If a proxy returns
From: Zvi Har'El [mailto:[EMAIL PROTECTED]]
Sent: 16 February 2002 08:37
On Fri, 15 Feb 2002 09:44:19 -0800, Ian Holsman wrote about Re: [PATCH]
mod_deflate:
I'm still not very happy about compressing EVERYTHING and excluding
certain browsers
as you would have to exclude IE
On Sat, 16 Feb 2002, Zvi Har'El wrote:
On Fri, 15 Feb 2002 09:44:19 -0800, Ian Holsman wrote about Re: [PATCH]
mod_deflate:
I'm still not very happy about compressing EVERYTHING and excluding
certain browsers
as you would have to exclude IE Netscape.
so
this is a
-1
Igor Sysoev wrote:
On Sat, 16 Feb 2002, Zvi Har'El wrote:
On Fri, 15 Feb 2002 09:44:19 -0800, Ian Holsman wrote about Re: [PATCH]
mod_deflate:
I'm still not very happy about compressing EVERYTHING and excluding
certain browsers
as you would have to exclude IE Netscape.
so
this is a
-1
Igor Sysoev wrote:
On Sat, 16 Feb 2002, Zvi Har'El wrote:
...
In my mod_deflate module (for Apache 1.3.x) I'd enabled by default
text/html only. You can add or remove another type with DeflateTypes
directive. Here are some recomendations:
application/x-javascript NN4 does not
Ian Holsman [EMAIL PROTECTED] writes:
In my mod_deflate module (for Apache 1.3.x) I'd enabled by default
text/html only. You can add or remove another type with DeflateTypes
directive. Here are some recomendations:
This is EXACTLY what we should be doing IMHO.
if a person wants to
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick
Ian Holsman [EMAIL PROTECTED] writes:
In my mod_deflate module (for Apache 1.3.x) I'd enabled by default
text/html only. You can add or remove another type with DeflateTypes
directive. Here are some
On Sat, 16 Feb 2002, Eli Marmor wrote:
Igor Sysoev wrote:
On Sat, 16 Feb 2002, Zvi Har'El wrote:
...
In my mod_deflate module (for Apache 1.3.x) I'd enabled by default
text/html only. You can add or remove another type with DeflateTypes
directive. Here are some
Justin Erenkrantz wrote:
On Sat, Feb 16, 2002 at 06:59:40PM +0100, Sander Striker wrote:
Wow! Obviously the code/default config need to be extremely
conservative!
Yes. But browsers change (evolve to better things we hope), so config has
my preference. Hardcoding in default rules is badness
On Sat, 16 Feb 2002, Ian Holsman wrote:
Justin Erenkrantz wrote:
On Sat, Feb 16, 2002 at 06:59:40PM +0100, Sander Striker wrote:
Wow! Obviously the code/default config need to be extremely
conservative!
Yes. But browsers change (evolve to better things we hope), so config has
my
Justin Erenkrantz [EMAIL PROTECTED] writes:
On Sat, Feb 16, 2002 at 06:59:40PM +0100, Sander Striker wrote:
Wow! Obviously the code/default config need to be extremely
conservative!
Yes. But browsers change (evolve to better things we hope), so config has
my preference.
Sander Striker wrote:
@@ -297,6 +287,7 @@
apr_table_setn(r-headers_out, Content-Encoding, gzip);
apr_table_setn(r-headers_out, Vary, Accept-Encoding);
+apr_table_unset(r-headers_out, Content-Length);
}
APR_BRIGADE_FOREACH(e, bb) {
Do you
I'm still not very happy about compressing EVERYTHING and excluding
certain browsers
as you would have to exclude IE Netscape.
so
this is a
-1 for this patch.
in order to change this checks need to be there with a directive to
ignore them (default:off)
Sander Striker wrote:
Sander Striker
From: Ian Holsman [mailto:[EMAIL PROTECTED]]
Sent: 15 February 2002 18:44
Hi,
I'm still not very happy about compressing EVERYTHING and excluding
certain browsers as you would have to exclude IE Netscape.
so this is a -1 for this patch.
in order to change this checks need to be there
Sander Striker wrote:
From: Ian Holsman [mailto:[EMAIL PROTECTED]]
Sent: 15 February 2002 18:44
Hi,
I'm still not very happy about compressing EVERYTHING and excluding
certain browsers as you would have to exclude IE Netscape.
so this is a -1 for this patch.
in order to change this
On Fri, 15 Feb 2002 09:44:19 -0800, Ian Holsman wrote about Re: [PATCH] mod_deflate:
I'm still not very happy about compressing EVERYTHING and excluding
certain browsers
as you would have to exclude IE Netscape.
so
this is a
-1 for this patch.
in order to change this checks need
81 matches
Mail list logo
