On 12/09/2006 07:02 PM, Justin Erenkrantz wrote:
> On 12/9/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
>> Thanks for giving the pointer to ap_meets_conditions. So content
>> compressed
>> by mod_deflate would not stand conditional requests based on ETags any
&
On 12/9/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
Thanks for giving the pointer to ap_meets_conditions. So content compressed
by mod_deflate would not stand conditional requests based on ETags any longer.
That would be bad. Would it help if we simply unset the ETag in mod_deflate?
mod_
On 12/09/2006 03:23 PM, Justin Erenkrantz wrote:
> On 12/9/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>>
>> Would the following patch address all your points for a CE mod_deflate
>> filter?
>
>
> No - this patch breaks conditional GETs which is wh
vented in the first place.
We don't live in a world that uses Transfer Encoding for gzip.
Firefox, MSIE, and Opera don't support it. So, dropping Content
Encoding support in mod_deflate is a non-starter.
We should have an implementation of deflate as a transfer encoding,
but it should
ts of large cached representations requires a
> strong etag, and it really isn't hard to provide one. It is better
> to not deflate the response at all than to interfere with caching.
Would the following patch address all your points for a CE mod_deflate filter?
No - this patch breaks c
isn't hard to provide one. It is better
> to not deflate the response at all than to interfere with caching.
Would the following patch address all your points for a CE mod_deflate filter?
Index: modules/filters/mod_deflate.c
===
ding: gzip" and another ask for the same URI
and does NOT supply "Accept-encoding: gzip"...
> then a conditional GET request is made containing ALL of the
> cached entity tags in an If-None-Match field
> (in accordance with the Vary requirements).
...and, currently, if
;deal with it" -- it just isn't a
very efficient cache.
The compromise I'd be willing to accept is to have mod_deflate support
the 'TE: gzip' request header and add 'gzip' to the Transfer-Encoding
bit - and to prefer that over any Accept-Encoding bits that are
we all (hopefully) agree that a weak ETag is ideally what
mod_deflate should add. But, the specs simply dropped the ball here
as doing that breaks conditional requests. If we could issue a weak
ETag and have it work for conditional requests, this would be easy and
be done by now.
We can't, so I
Tag case
just fine, FWIW.)
The compromise I'd be willing to accept is to have mod_deflate support
the 'TE: gzip' request header and add 'gzip' to the Transfer-Encoding
bit - and to prefer that over any Accept-Encoding bits that are sent.
The ETag can clearly remain the same in
fre 2006-12-08 klockan 22:28 +0100 skrev Henrik Nordstrom:
> A strong ETag must be unique among all variants of a given URI, that is
> all different forms of entities that may reside under the URI and all
> their past and future versions.
Forgot the last piece there which clears many doubts:
Ent
fre 2006-12-08 klockan 11:44 -0800 skrev Roy T. Fielding:
> In other words, Henrik has it right. It is our responsibility to
> assign different etags to different variants because doing otherwise
> may result in errors on shared caches that use the etag as a variant
> identifier.
Thanks ;-)
Reg
fre 2006-12-08 klockan 15:03 -0500 skrev [EMAIL PROTECTED]:
> To ONLY ever use ETag as a the end-all-be-all for variant
> identification is, itself, a mistake.
Well, this area of the HTTP specs is pretty clear in my eyes, but then
I have read it up and down too many times unwinding the tangled
ECTED] writes:
Argh, my stupid ISP is losing apache email again because they use
spamcop.
On Dec 7, 2006, at 2:45 PM, Henrik Nordstrom wrote:
> tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz:
>
>> -1 on adding semantic junk to the existing ETag (and keeping it
>>
Any generated ETag from
mod_deflate
should either be the original strong version or a weak version of any
previous etag. mod_deflate by *definition* is just creating a weak
version of the prior entity.
No, it is changing the content-encoding value, which is changing the
entity. The purpose of
fre 2006-12-08 klockan 14:40 +0100 skrev Justin Erenkrantz:
> Uh, no, they *are* semantically equivalent - but, yes, not
> syntactically (bit-for-bit) equivalent. You inflate the response and
> you get exactly what the ETag originally represented.
To entities is only semantically equivalent if t
tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz:
> -1 on adding semantic junk to the existing ETag (and keeping it
> strong); that's blatantly uncool. Any generated ETag from mod_deflate
> should either be the original strong version or a weak version of any
&
fre 2006-12-08 klockan 14:40 +0100 skrev Justin Erenkrantz:
> Uh, no, they *are* semantically equivalent - but, yes, not
> syntactically (bit-for-bit) equivalent. You inflate the response and
> you get exactly what the ETag originally represented.
To entities is only semantically equivalent if t
fre 2006-12-08 klockan 14:47 +0100 skrev Justin Erenkrantz:
> mod_deflate is certainly not creating a new resource
It is creating a new HTTP entity. Not a new object on your server, but
still a new unique HTTP entity with different characteristics from the
identity encoding.
If we were talk
On 12/8/06, Henrik Nordstrom <[EMAIL PROTECTED]> wrote:
The protocol is quite fine as it is, and not easy to change. As it is
now it's mainly a matter of understanding that mod_deflate does create a
completely new entity from the original one. To the protocol it's
exactly the sa
On 12/8/06, Henrik Nordstrom <[EMAIL PROTECTED]> wrote:
No, that won't work. You still be just as non-conforming by doing that.
But if mod_deflate may to produce different octet-level results on
different requests for the same original entity then it must do this in
addition to other
tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz:
> -1 on adding semantic junk to the existing ETag (and keeping it
> strong); that's blatantly uncool. Any generated ETag from mod_deflate
> should either be the original strong version or a weak version of any
&
tor 2006-12-07 klockan 02:31 +0100 skrev Justin Erenkrantz:
> mod_deflate should just add the W/ prefix if it's not already there. --
> justin
No, that won't work. You still be just as non-conforming by doing that.
But if mod_deflate may to produce different octet-level resu
On 12/7/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
mod_deflate should just add the W/ prefix if it's not already there. -- justin
But, that'll break caches as we're not allowed to serve If-Match with
weak entity tags. Feh.
-1 on adding semantic junk to the exist
On 12/7/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
Entities gzip:ed by mod_deflate still carries the same ETag as the
plain entiy,
causing inconsistency in ETag aware proxy caches.
I'll have a look later and see if I can fix it, but let me know if there
is already a patch in the
Roy T. Fielding wrote:
Protocol issues really should be brought up on the dev list, with an
appropriate subject, and not left in bugzilla.
FWIW, there was a dev list thread on this 3 years ago with the subject
"mod_deflate and transfer / content encoding problem".
http:
Protocol issues really should be brought up on the dev list, with an
appropriate subject, and not left in bugzilla.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
Entities gzip:ed by mod_deflate still carries the same ETag as the
plain entiy,
causing inconsistency in ETag aware
On 10/29/2006 11:41 PM, Nick Kew wrote:
> On Sun, 2006-10-29 at 23:21 +0100, Ruediger Pluem wrote:
>
>
>>>Backport to 2.2.x ? I'm still using 2.0.x - LOL.
>>
>>Have you tried to apply the patches for 2.2.x to 2.0.x? I haven't tried so,
>>but
&
On Sun, 2006-10-29 at 23:21 +0100, Ruediger Pluem wrote:
> > Backport to 2.2.x ? I'm still using 2.0.x - LOL.
>
> Have you tried to apply the patches for 2.2.x to 2.0.x? I haven't tried so,
> but
> I think mod_deflate has not changed that much between 2.2.x and 2.0
quote from mod_jk's docs:
>>>
>>>
>>>JkOptions +FlushPackets
>>>JkOptions FlushPackets, you ask mod_jk to flush Apache's connection
>>>buffer after each AJP packet chunk received from Tomcat.
>>>
>>>
>>>mod_def
>> imagine a simple CGI-script:
>>
>>
>> #!/usr/bin/perl
>> print "Content-Encoding: identity\n";
>> print "Content-Type: text/plain\n";
>> print "\n";
>> print "test";
>>
>>
>> AFAIK, &q
;
>
>
> AFAIK, "identity" indicates, that no transformation is being done on the
> content.
>
> IMHO, mod_deflate should implement the following logic:
>
> Content-Encoding-header already present?
> yes: do nothing, just forward content
> no: add Co
Hi,
imagine a simple CGI-script:
#!/usr/bin/perl
print "Content-Encoding: identity\n";
print "Content-Type: text/plain\n";
print "\n";
print "test";
AFAIK, "identity" indicates, that no transformation is being done on the
content.
IMHO
+FlushPackets
>> JkOptions FlushPackets, you ask mod_jk to flush Apache's connection
>> buffer after each AJP packet chunk received from Tomcat.
>>
>>
>> mod_deflate breaks that. I know the issue from ssh already.
>
> I know. There are some patches to
On Wednesday 25 October 2006 07:05, Plüm, Rüdiger, VF EITO wrote:
> > mod_deflate breaks that. I know the issue from ssh already.
Yep. And Paul's reply refers only to /trunk/, not to released versions.
> I know. There are some patches to fix that. These are proposed for backp
> -Ursprüngliche Nachricht-
> Von: news
> Gesendet: Mittwoch, 25. Oktober 2006 00:36
> An: dev@httpd.apache.org
> Betreff: mod_deflate and flush?
>
>
> Hi,
>
> JSP (via mod_jk) and maybe other plugins sometimes flush the
> connection,
> so that th
>> JSP (via mod_jk) and maybe other plugins sometimes flush the connection,
>> so that the browsers receive everything that's stuck in some internal
>> buffer. Here's a quote from mod_jk's docs:
>
> mod_deflate supports metadata buckets of the FLUSH typ
Sven Köhler wrote:
> Hi,
>
> JSP (via mod_jk) and maybe other plugins sometimes flush the connection,
> so that the browsers receive everything that's stuck in some internal
> buffer. Here's a quote from mod_jk's docs:
mod_deflate supports metadata buckets of the
;s connection
buffer after each AJP packet chunk received from Tomcat.
mod_deflate breaks that. I know the issue from ssh already. Some special
treatment has to be done, so that flushing happens inspite of the
compression. Can mod_deflate do that too? Or would that break the
HTTP-standard?
IMHO, th
On 07/18/2006 01:05 AM, Henrik Nordstrom wrote:
>
> It's not in case of C-L. For a starter HEAD is used by quite many robots
> with simplistic caches to verify that the copy they have is current and
> correct.
>
> The RFC is quite strict that entity headers of a HEAD response SHOULD
> match th
That makes sence and explains why i couldn't use a HEAD request to ge the content-lenght of a list of file while mod_deflate was on.On 7/18/06, William A. Rowe, Jr.
<[EMAIL PROTECTED]> wrote:Jorge Schrauwen wrote:
> I might be getting this all wrong but doesn't the Con
tis 2006-07-18 klockan 00:47 +0200 skrev Ruediger Pluem:
> And this is exactly the question: Is it ok for
> the HEAD response to differ from the GET response with respect to T-E
> and C-L headers
It's not in case of C-L. For a starter HEAD is used by quite many robots
with simplistic caches to ve
a HEAD and a GET.
> I'd imagine about <1%. and i'm also guessing that most of these would
> be from robots (who don't care about response time) so this patch will
Maybe the robots don't care, but some of these search robots are doing HEAD
requests
when validating thei
On 07/18/2006 12:06 AM, Jorge Schrauwen wrote:
> I might be getting this all wrong but doesn't the Content-Lenght require
> mod_deflate to run? for the correct lenght to be set?
Not really, because provided that you do not compress a very small body the
response
is send as T-E chun
On 18/07/2006, at 8:06 AM, Ruediger Pluem wrote:
(I can't think of any which do this BTW)
are you seeing a problem somewhere Ruediger?
The biggest problem at the moment is that I fear that I do not get
your point correctly :-).
So some explanations from your side would be very helpful to
Jorge Schrauwen wrote:
I might be getting this all wrong but doesn't the Content-Lenght require
mod_deflate to run? for the correct lenght to be set?
If we won't send content-length, but instead send content-encoding chunked,
then there's no reason to compute content lengt
On 07/17/2006 11:50 PM, Ian Holsman wrote:
> personally I think GET & HEAD processing should be identical until the
> very last moment.
Agreed in general, but in the case of mod_deflate doing a compression on
a HEAD wastes an unnecessary high count of CPU cycles IMHO.
> thi
I might be getting this all wrong but doesn't the Content-Lenght require mod_deflate to run? for the correct lenght to be set?On 7/17/06, Ian Holsman <
[EMAIL PROTECTED]> wrote:personally I think GET & HEAD processing should be identical until
the very last moment.this avoids b
personally I think GET & HEAD processing should be identical until
the very last moment.
this avoids bugs creeping in which process the body for some reason
and add a header after mod_deflate is run
(I can't think of any which do this BTW)
are you seeing a problem somewhere
The following patch avoids that the deflate output filter wastes cycles in
compressing the body of a header only request that gets thrown away by http
header filter afterwards anyway.
OTH a HEAD and a GET request differ regarding regarding the T-E and C-L headers
(everything else is the same). So I
+1 from me.
On 19/04/2006, at 4:37 AM, Brian J. France wrote:
This was talked about a few weeks back but I don't think anything
ever came of it. The patch below would allow mod_deflate to
compress internal redirects while still skipping sub requests.
I have been running this
Brian J. France wrote:
The patched block of code is only called when f->ctx is NULL and hasn't
been setup yet by mod_deflate. I would assume when a sub request would
get added the ctx for its ap_filter_t struct would be NULL and
f->r->main would be the top request so the
eak the
filter stack
by yanking the deflate filter out from the middle of servicing a
request, e.g.
when a subrequest is included midstream.
The patched block of code is only called when f->ctx is NULL and
hasn't been setup yet by mod_deflate. I would assume when a sub
request w
@@ -240,7 +240,7 @@
const char *encoding;
/* only work on main request/no subrequests */
-if (!ap_is_initial_req(r)) {
+if (r->main != NULL) {
ap_remove_output_filter(f);
Actually, explain to me how this code successfully leaves the http protocol
la
This patch is correct. +1 to any/all branches as applicable.
Brian J. France wrote:
This was talked about a few weeks back but I don't think anything ever
came of it. The patch below would allow mod_deflate to compress
internal redirects while still skipping sub requests.
I have
This was talked about a few weeks back but I don't think anything
ever came of it. The patch below would allow mod_deflate to compress
internal redirects while still skipping sub requests.
I have been running this on my personal server for a few weeks now
with no issues.
Let the v
est(r) (r->main != NULL)
> I think we decided against that and just have mod_deflate changed to:
>
> if(r->main != NULL) {
>
If the question is whether to avoid using a macro, then
I'm +1 (the test is a well known documented f
Brian J. France wrote:
r->main will be NULL, but r->prev is valid for internal redirects. This
was talked about on IRC and Brian Akins mentioned creating a
ap_is_subrequest call:
#define ap_is_subrequest(r) (r->main != NULL)
I think we decided against that and just have mo
I was digging into why mod_deflate wasn't compressing some pages and
found that any internal redirects (rewriterule) don't get compress.
That is because of this code:
/* only work on main request/no subrequests */
if (!ap_is_ini
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;
-
--
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:04:20.0 -0500
@@ -518,7 +518,10 @@
}
/* read */
-apr_bucket_read(e, &data, &len, APR_BLOCK_READ);
+
ssed pages for "/page.html" requests
2) and the "Save file" message box for the "/dir/" requests.
My mod_deflate allows optionally to add "Vary" header to compressed
response only.
So you still run the risk of only getting one variant 'stuck' in a
downs
same approach. If you can't do ALL
of the "Vary:" rules then safest thing to do is just reject it all
and let someone ( or something ) else worry about getting you
the right content.
This was also SQUID's philosophy with regards to "Vary:"
in the not-too-distant pas
eased.
If MSIE 5.5 is configured to work via proxy with HTTP/1.0, then
MSIE will never send "Accept-Encoding" header, and it would refuse
the compressed content.
This is why my mod_deflate for Apache 1.3 by default does not compress
response for proxied requests.
Microsoft Internet Explo
Hi,
> I did not talk about traffic, but bandwidth. I read that you're concerned
> about server's bandwidth and so it would be good if the clients get
> uncompressed content from the cache rather than compressed from the server.
> The trick to achieve both is *to deliver uncompressed content* wi
than a compressed one from the original
> > > server and (2) even if it wasn't, it still might save traffic and
> > > thus money for the server operator.
> >
> > If I do understand correctly, you say, that not compressing the content
> > saves bandwidth? Well t
x27;t, it
> > still might save traffic and thus money for the server operator.
>
> If I do understand correctly, you say, that not compressing the content
> saves bandwidth? Well then turn off mod_deflate and you're done. No need to
> change anything here, IMHO.
Could you p
> still might save traffic and thus money for the server operator.
If I do understand correctly, you say, that not compressing the content
saves bandwidth? Well then turn off mod_deflate and you're done. No need to
change anything here, IMHO.
nd
--
Gefunden auf einer "Webdesigner"
Hi,
[...]
> > To put this straight: I was thinking about web servers behind
> > V.90/ISDN/ADSL lines where _that_ line usually will be the bottleneck
> > on any connections to the outside world and about caching proxies
> > in that outside world ...
>
> Yes, but if you do compression because som
This has been discussed many times before and no one
seems to understand what the fundamental problem is.
It is not with the servers at all, it is with the CLIENTS.
What both of you are saying is true... whether you "Vary:"
on "Content-encoding" and/or "User-agent" or not... there
is a risk of
On 11/04/2005 07:36 AM, Florian Zumbiehl wrote:
[..cut..]
>
>>Maybe I'm pessimistic, but I think, omitting the Vary header for
>>uncompressed ressources will lead to "poisoned" caches, which statistically
>>nearly always will request the uncompressed variant and so actually
>>*add* load to yo
Hi,
> Yes, that is the point. The Vary header describes which header(s) was used
> to decide, which content actually would be delivered. That's what HTTP
> specifies.
To be exact, I'd say that HTTP specifies that it's about representation and
not about content - which might even be the point here
* Florian Zumbiehl <[EMAIL PROTECTED]> wrote:
> While configuring and testing my new and shiny Apache 2, I noticed that
> mod_deflate sends a Vary: Content-Encoding header whenever a resource
> could potentially be compressed, no matter whether it actually is
> compressed
Hi,
While configuring and testing my new and shiny Apache 2, I noticed that
mod_deflate sends a Vary: Content-Encoding header whenever a resource
could potentially be compressed, no matter whether it actually is
compressed in that particular response. That certainly should
work, but in situations
On 17-Apr-05, at 5:30 PM, Roy T. Fielding wrote:
On Apr 17, 2005, at 1:25 PM, [EMAIL PROTECTED] wrote:
+
+ *) mod_deflate: Merge the Vary header, isntead of Setting it. Fixes
+ applications that send the Vary Header themselves, and also
apply
+ mod_defalte as an output filter. [Paul
On Apr 17, 2005, at 1:25 PM, [EMAIL PROTECTED] wrote:
+
+ *) mod_deflate: Merge the Vary header, isntead of Setting it. Fixes
+ applications that send the Vary Header themselves, and also apply
+ mod_defalte as an output filter. [Paul Querna]
*) mod_rewrite: use buffered I/O for
On Tue, Nov 23, 2004 at 07:51:19PM +, Joe Orton wrote:
> On Mon, Nov 22, 2004 at 11:40:29PM -0800, Roy T. Fielding wrote:
> > Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>:
> >
> > > >Okay, but why the next three lines? Why would Content-Encoding: gzip
> > > >*ever* be set on a 304?
> >
On Mon, Nov 22, 2004 at 11:40:29PM -0800, Roy T. Fielding wrote:
> Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>:
>
> > >Okay, but why the next three lines? Why would Content-Encoding: gzip
> > >*ever* be set on a 304?
>
> Because Content-* header fields in a 304 response describe
> what th
On Mon, 22 Nov 2004, Roy T. Fielding wrote:
> Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>:
>
> > >Okay, but why the next three lines? Why would Content-Encoding: gzip
> > >*ever* be set on a 304?
>
> Because Content-* header fields in a 304 response describe
> what the response entity woul
Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>:
> >Okay, but why the next three lines? Why would Content-Encoding: gzip
> >*ever* be set on a 304?
Because Content-* header fields in a 304 response describe
what the response entity would contain if it were a 200 response.
Therefore, the heade
--On Monday, November 22, 2004 5:30 PM -0500 [EMAIL PROTECTED] wrote:
Suggestion: Make sure someone can compress any response
they want via config but then make sure to NOT recommend
doing certain things and let them swim at their own risk.
No lifeguard on duty.
+1. -- justin
> At 10:26 AM 11/22/2004, Cliff Woolley wrote:
>>>>>>On Mon, 22 Nov 2004, Joe Orton wrote:
>>
>>> There's another mod_deflate vs 304 response problem which is being
>>> triggered by ViewCVS on svn.apache.org: when a CGI script gives a
>>&g
At 10:26 AM 11/22/2004, Cliff Woolley wrote:
>On Mon, 22 Nov 2004, Joe Orton wrote:
>
>> There's another mod_deflate vs 304 response problem which is being
>> triggered by ViewCVS on svn.apache.org: when a CGI script gives a
>> "Status: 304" response the bri
On Mon, 22 Nov 2004, Joe Orton wrote:
> > Okay, but why the next three lines? Why would Content-Encoding: gzip
> > *ever* be set on a 304?
>
> I was wondering that too. The answer to the latter is that it *won't*
> be sent for a 304 because the http_header filter knows better than that.
Well, o
On Mon, Nov 22, 2004 at 11:26:18AM -0500, Cliff Woolley wrote:
> On Mon, 22 Nov 2004, Joe Orton wrote:
>
> > There's another mod_deflate vs 304 response problem which is being
> > triggered by ViewCVS on svn.apache.org: when a CGI script gives a
> > "Status: 30
Cliff Woolley wrote:
Okay, but why the next three lines? Why would Content-Encoding: gzip
*ever* be set on a 304?
In theory the 304 might be in response to a freshness check on the
particular variant that was compressed. (Assuming I am not mixing up my
content and transfer encodings).
Regards,
On Mon, 22 Nov 2004, Joe Orton wrote:
> There's another mod_deflate vs 304 response problem which is being
> triggered by ViewCVS on svn.apache.org: when a CGI script gives a
> "Status: 304" response the brigade contains a CGI bucket then the EOS,
> so fails the "
There's another mod_deflate vs 304 response problem which is being
triggered by ViewCVS on svn.apache.org: when a CGI script gives a
"Status: 304" response the brigade contains a CGI bucket then the EOS,
so fails the "if this brigade begins with EOS do nothing" test added
On Mon, 11 Oct 2004, [ISO-8859-15] André Malo wrote:
> > It seems that calling an internal redirect from anywhere in an output
> > filter is completely wrong.
>
> Nope. The real problem is that it's a *redirect within a subrequest*.
Erm - it seems to me you're both right. Surely the underlying p
make mod_cgi{d} create a full subrequest, that
> would therefore use the same filter chain, and therefore mod_deflate
> would properly encode the content.
That solves the symptoms of this particular issue, but not the real problem.
> It seems that calling an internal redirect from
same filter
chain.
- If the subrequest is on a CGI, and that CGI sends a redirect
(Location:), mod_cgi{d} creates an internal redirect, which does *not*
use the same filter chain. Any output from this redirect does not get
put into the same chain as the Main Request.
- Meanwhile, mod_deflate, which
On 24 Sep 2004 16:15:31 +0200, Francois PESCE <[EMAIL PROTECTED]> wrote:
> For example, in a reverse proxy architecture, this feature may allow to
> gzip/deflate documents according to their Content-Type, and not only to
> the request-uri or other client-side provided information that may hide
> t
Hi,
Today, mod_setenvif does not provide a way to "set environment
variable if" something is interesting in response headers.
For example, in a reverse proxy architecture, this feature may allow to
gzip/deflate documents according to their Content-Type, and not only to
the request-uri
At 06:23 AM 9/22/2004, Marco wrote:
>> zlib 1.2.1 is current, it's hard to tell from your typo which
>> you used(?)
>> Try zlib 1.1.4 sources unpacked into the httpd source tree
>> srclib/zlib/
>> location.
>
>i have used 1.1.4 and i wrote this in my first mail ;)
You wrote 1.4.1 . Anyways, we
> zlib 1.2.1 is current, it's hard to tell from your typo which
> you used(?)
> Try zlib 1.1.4 sources unpacked into the httpd source tree
> srclib/zlib/
> location.
i have used 1.1.4 and i wrote this in my first mail ;)
At 02:12 AM 9/22/2004, Marco Glatz wrote:
>hello,
>
>i wanted to build httpd 2.0.51 with mod_ssl and mod_deflate, using vc++ 6.0
>SP6 on win2k SP4, but i get this error-message:
>
>deflate.obj : error LNK2001: unresolved external symbol _compressBound
zlib 1.1.4 sources were te
hello,
i wanted to build httpd 2.0.51 with mod_ssl and mod_deflate, using vc++ 6.0
SP6 on win2k SP4, but i get this error-message:
deflate.obj : error LNK2001: unresolved external symbol _compressBound
but only when i build the release-build, debug-build works with no problems.
i used zlib
* Nick Kew <[EMAIL PROTECTED]> wrote:
> On Wed, 18 Aug 2004, Brian Akins wrote:
>
> > Shouldn't we still set "Vary: Accept-Encoding" if no-gzip is set?
>
> Hmmm, makes sense. +1
Nope. mod_deflate doesn't know whether it depends on the request (more
On Wed, 18 Aug 2004, Brian Akins wrote:
Shouldn't we still set "Vary: Accept-Encoding" if no-gzip is set? Example,
if I use SetEnvIf to disallow gzip for some browsers, shouldn't we still tell
proxies to vary on "Accept-Encoding"? mod_deflate will send the Vary
On Wed, 18 Aug 2004, Brian Akins wrote:
> Shouldn't we still set "Vary: Accept-Encoding" if no-gzip is set?
Hmmm, makes sense. +1
Should we be looking at a wholesale backport from 2.1-head? There are
a number of minor bugfixes, as well as the inflate output filter.
--
Nick Kew
201 - 300 of 464 matches
Mail list logo
