On 8/24/2011 4:54 PM, Roy T. Fielding wrote:
On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote:
To be clear, I am more than willing to rewrite the part on
Ranges such that the above is explicitly forbidden in HTTP.
I am not sure what the WG would agree to, but I am quite certain
that part of
On Aug 24, 2011, at 4:39 PM, William A. Rowe Jr. wrote:
On 8/24/2011 4:54 PM, Roy T. Fielding wrote:
On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote:
To be clear, I am more than willing to rewrite the part on
Ranges such that the above is explicitly forbidden in HTTP.
I am not sure what
On 8/24/2011 6:43 PM, Roy T. Fielding wrote:
On Aug 24, 2011, at 4:39 PM, William A. Rowe Jr. wrote:
On 8/24/2011 4:54 PM, Roy T. Fielding wrote:
On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote:
To be clear, I am more than willing to rewrite the part on
Ranges such that the above is
On Aug 24, 2011, at 4:56 PM, Roy T. Fielding wrote:
On Aug 24, 2011, at 8:35 AM, Tim Bannister wrote:
On Tue, Aug 23, 2011, Roy T. Fielding wrote:
And the spec says ...
When a client requests multiple ranges in one request, the
server SHOULD return them in the order that they appeared
On Aug 24, 2011, at 5:54 PM, Roy T. Fielding wrote:
On Aug 24, 2011, at 1:56 PM, Roy T. Fielding wrote:
To be clear, I am more than willing to rewrite the part on
Ranges such that the above is explicitly forbidden in HTTP.
I am not sure what the WG would agree to, but I am quite certain
http://seclists.org/fulldisclosure/2011/Aug/175
I haven't looked into it so far. And I am not sure I will have time today.
-Original Message-
From: Stefan Fritsch [mailto:s...@sfritsch.de]
Sent: Dienstag, 23. August 2011 13:09
To: dev@httpd.apache.org
Subject: DoS with mod_deflate range requests
http://seclists.org/fulldisclosure/2011/Aug/175
I haven't looked into it so far. And I am not sure I
2011/8/23 Stefan Fritsch s...@sfritsch.de:
http://seclists.org/fulldisclosure/2011/Aug/175
I haven't looked into it so far. And I am not sure I will have time today.
it is sending HEAD requests with lots of ranges
HEAD / HTTP/1.1
Host:
Range:bytes=0-,5-1,5-2,5-3,.
the code in
On Tue, Aug 23, 2011 at 02:15:16PM +0200, Lazy wrote:
2011/8/23 Stefan Fritsch s...@sfritsch.de:
http://seclists.org/fulldisclosure/2011/Aug/175
I haven't looked into it so far. And I am not sure I will have time today.
it is sending HEAD requests with lots of ranges
HEAD / HTTP/1.1
Host:
On 8/23/2011 6:08 AM, Stefan Fritsch wrote:
http://seclists.org/fulldisclosure/2011/Aug/175
I haven't looked into it so far. And I am not sure I will have time today.
Until range can be completely addressed, avoiding excessive numbers of
ranges (tricky) or overlapping ranges (pretty
numbers
of ranges (tricky) or overlapping ranges (pretty
straightforward)... what about simply disabling deflate on range
requests?
There is this PR:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49772
mod_deflate kicks itself out on Content-Range responses but not on
multipart/byteranges
://issues.apache.org/bugzilla/show_bug.cgi?id=49772
mod_deflate kicks itself out on Content-Range responses but not on
multipart/byteranges
This may be one of the issues. But as Rüdiger pointed out, there is
also an issue without mod_deflate.
From looking at the code, I think the problem
On 8/23/2011 1:49 PM, Stefan Fritsch wrote:
From looking at the code, I think the problem is the bucket structs.
With N the number of requested ranges, the initial brigade is
partitioned into 2*N buckets at the maximum. Then those buckets are
copied into the output brigade N times, which
On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote:
I suggest we should be parsing and reassembling the list before we
start the bucket logic.
I propose we satisfy range requests in the only sensible manner, returning
the ranges in sequence,
yeah, overlapping
On 8/23/2011 4:00 PM, Greg Ames wrote:
On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wrote:
I suggest we should be parsing and reassembling the list before we
start the bucket logic.
I propose we satisfy range requests in the only sensible manner, returning
the
Am 23.08.2011 20:52, schrieb Mohamed Dawaina:
please tell me how to unsubscribe from this mailing list
what about looking in the mail-header or login with your acount
you have registered?
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: mailto:dev-h...@httpd.apache.org
On Tuesday 23 August 2011, William A. Rowe Jr. wrote:
On 8/23/2011 4:00 PM, Greg Ames wrote:
On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wrote:
I suggest we should be parsing and reassembling the list
before we start the bucket logic.
I propose we satisfy range
On Aug 23, 2011, at 2:34 PM, William A. Rowe Jr. wrote:
On 8/23/2011 4:00 PM, Greg Ames wrote:
On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wrote:
I suggest we should be parsing and reassembling the list before we
start the bucket logic.
I propose we satisfy range
On Tuesday 02 August 2011, Torsten Förtsch wrote:
I don't know how common this situation is. It came up in the
modperl test suite (t/filter/both_str_req_mix.t). This test
contructs a filter chain like
modperl filter
INCLUDES
another modperl filter
DEFLATE
The INCLUDES
Hi Eric,
On 02.08.2011 04:40, Eric Covener wrote:
I'm setting up a new system to test httpd releases, with a crufty OS
that doesn't have good packaged prereqs and doesn't have years of my
own kludges giving me anything for free.
I've built and installed zlib into a random directory. I
Line 48 is surrounded by
if test x$ap_zlib_base = x; then
and ap_zlib_base ist set when using --with-z. So in this case the
automatic detection part should be skipped.
What problem do you actually observe?
Can't get it to misbehave at all this morning, even in a new scratch
directory,
On 02.08.2011 13:00, Eric Covener wrote:
Line 48 is surrounded by
if test x$ap_zlib_base = x; then
and ap_zlib_base ist set when using --with-z. So in this case the
automatic detection part should be skipped.
What problem do you actually observe?
Can't get it to misbehave at all this
Hi Stefan,
thanks for applying.
On Saturday, 30 July 2011 17:41:39 Torsten Förtsch wrote:
The last if statement should read as follows to avoid the loop:
if (APR_BUCKET_IS_METADATA(e)) {
e = APR_BUCKET_NEXT(e);
continue;
}
I don't
I'm setting up a new system to test httpd releases, with a crufty OS
that doesn't have good packaged prereqs and doesn't have years of my
own kludges giving me anything for free.
I've built and installed zlib into a random directory. I can't see
how recent work in the area broke this, but
Hi,
the DEFLATE output filter contains this piece of code (as of server magic
number 20110724)
if (!ctx) {
char *token;
const char *encoding;
/* Delay initialization until we have seen some data */
e = APR_BRIGADE_FIRST(bb);
while (1) {
If mod_deflate is not built, the Apache-Test httpd will not start.
Index: httpd/test/framework/trunk/t/conf/extra.conf.in
===
--- httpd/test/framework/trunk/t/conf/extra.conf.in(revision 1062532)
+++ httpd/test/framework
On 13 Aug 2010, at 8:25 PM, Bryan McQuade wrote:
In looking at the source for mod_deflate:
http://www.google.com/codesearch/p?hl=en#lfs-jRjrQ3s/trunk/modules/
filters/mod_deflate.cl=524
It appears to insert Vary Accept-Encoding header into every candidate
response by default, which is what
Hi,
In looking at the source for mod_deflate:
http://www.google.com/codesearch/p?hl=en#lfs-jRjrQ3s/trunk/modules/filters/mod_deflate.cl=524
It appears to insert Vary Accept-Encoding header into every candidate
response by default, which is what you would expect.
But the instructions here: http
suggest adding a line to manually add Vary Accept-Encoding to responses:
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
Your text says Accept-Encoding but the config snippet says User-Agent.
--
Eric Covener
cove...@gmail.com
Sorry, dumb question. Need to read before sending. :) Thank you.
On Fri, Aug 13, 2010 at 3:03 PM, Eric Covener cove...@gmail.com wrote:
suggest adding a line to manually add Vary Accept-Encoding to responses:
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent
On 27.07.2010 16:26, PIPIT isnatia wrote:
Thanks for your reply.
if the source code mod_deflate, i have got it. But dependecies that is include
in mod_deflate, i have not found it.
I have sent an email on httpd-apache, but there is no response.
Please be a bit patient and more specific
On 27.07.2010 10:05, PIPIT isnatia wrote:
Hi all,,i'm newbie here...
I am looking for mod_deflate package, i mean all contents in mod_deflate. where
i can find it?
mod_deflate is part of the Apache Web Server (version 2.0 and 2.2). You
can find download links for Apache on
http
On Tuesday 22 June 2010, Plüm, Rüdiger, VF-Group wrote:
I am currently +0 on wether to use the patch above or my original
proposal. Both have its pros and cons (Saving more CPU vs. be more
picky about caching and implement an RFC SHOULD).
I have now commited your original patch because it is
On 06/21/2010 11:37 PM, William A. Rowe Jr. wrote:
On 6/21/2010 4:00 PM, Stefan Fritsch wrote:
As I understand it, Rüdiger's patch may be better for caching but uses
more CPU cycles. But it uses way less CPU than no patch at all.
Therefore I propose to include that patch unless there is
On Tue, Jun 22, 2010 at 2:37 AM, Ruediger Pluem rpl...@apache.org wrote:
Does someone still have Eric's patch? Seems that I can't find it right now.
This is what I have, but I never got off the fence back then much less now:
Index: modules/filters/mod_deflate.c
-Original Message-
From: Eric Covener
Sent: Dienstag, 22. Juni 2010 15:33
To: dev@httpd.apache.org
Subject: Re: mod_deflate DoS using HEAD
On Tue, Jun 22, 2010 at 2:37 AM, Ruediger Pluem
rpl...@apache.org wrote:
Does someone still have Eric's patch? Seems that I can't
On Thursday 16 July 2009, William A. Rowe, Jr. wrote:
Plüm, Rüdiger, VF-Group wrote:
Good point. So your patch would invalidate a cached entity if the
response to a GET delivered a C-L header, since HEAD and GET
would deliver different C-L headers.
OTOH I think only very small or
On 6/21/2010 4:00 PM, Stefan Fritsch wrote:
As I understand it, Rüdiger's patch may be better for caching but uses
more CPU cycles. But it uses way less CPU than no patch at all.
Therefore I propose to include that patch unless there is clear
consensus that Eric's patch is to be
Bryan McQuade wrote:
Are there any cases where it's important for ap_pass_bridgade to pass
on an empty brigade? Doesn't sound like it, but since this is a core
library change I want to double check.
When handling a CONNECT request, the response will have no body. In
mod_proxy, the CONNECT
Paul Fee wrote...
Bryan McQuade wrote:
Are there any cases where it's important for ap_pass_bridgade to pass
on an empty brigade? Doesn't sound like it, but since this is a core
library change I want to double check.
When handling a CONNECT request, the response will have no body. In
On 2 Jun 2010, at 10:49, Joe Orton wrote:
Maybe we should have a strict API here rather than a loose one:
filters MUST NOT pass an empty brigade down the filter chain.
That's not really an API, it's a rule, and pretty-much unenforcable.
I recollect one problem that bit some of my modules
On Wed, Jun 2, 2010 at 3:37 AM, Nick Kew n...@webthing.com wrote:
On 2 Jun 2010, at 10:49, Joe Orton wrote:
Maybe we should have a strict API here rather than a loose one:
filters MUST NOT pass an empty brigade down the filter chain.
That's not really an API, it's a rule, and pretty-much
On 2 Jun 2010, at 12:17, Brian Pane wrote:
Wait a minute...why not just change the implementation of
ap_pass_brigade so that it returns APR_SUCCESS immediately
when passed an empty brigade? That would solve the problem
globally.
That's just too sensible for this thread :)
--
Nick Kew
:) Great idea Brian.
I can submit a patch for this if it'd be helpful. Just let me know if
you'd like us to prepare a patch for this.
Are there any cases where it's important for ap_pass_bridgade to pass
on an empty brigade? Doesn't sound like it, but since this is a core
library change I want
chain, mod_deflate just
passes the empty brigade through to the next filter:
/* Do nothing if asked to filter nothing. */
if (APR_BRIGADE_EMPTY(bb)) {
return ap_pass_brigade(f-next, bb);
}
2. Control eventually reaches core_output_filter, which sends the
response headers.
3
chain, bad things happen:
1. On the first trip through the output filter chain, mod_deflate just
passes the empty brigade through to the next filter:
/* Do nothing if asked to filter nothing. */
if (APR_BRIGADE_EMPTY(bb)) {
return ap_pass_brigade(f-next, bb);
}
2. Control
nothing.
According to this, mod_deflate should not pass the empty brigade
along, and your module also should not be passing and empty brigade to
mod_deflate.
Eric, others, should we submit a patch to mod_deflate to change its
behavior to be consistent with the output filter guide?
On Tue, Jun 1
-Original Message-
From: Bryan McQuade
Sent: Dienstag, 1. Juni 2010 16:54
To: dev@httpd.apache.org
Cc: mdste...@google.com
Subject: Re: mod_deflate handling of empty initial brigade
The guide to writing output filters says:
https://httpd.apache.org/docs/trunk/developer
. But, for good defensive programming, filters should be prepared
to accept an empty brigade, and do nothing.
IMHO do nothing means the same thing as pass it down the chain. So I think
mod_deflate does the correct thing here.
On the contrary, the link above specifically recommends putting
On 1 Jun 2010, at 15:53, Bryan McQuade wrote:
According to this, mod_deflate should not pass the empty brigade
along, and your module also should not be passing and empty brigade to
mod_deflate.
Eric, others, should we submit a patch to mod_deflate to change its
behavior to be consistent
I went ahead and created a bug entry/patch to make the (trivial)
change to mod_deflate to make it conform to the Guide to writing
output filters:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49369
Brian, does this patch to mod_deflate fix your problem?
Nick, does this change seem
On Tue, Jun 1, 2010 at 10:28 AM, Matthew Steele mdste...@google.com wrote:
I went ahead and created a bug entry/patch to make the (trivial)
change to mod_deflate to make it conform to the Guide to writing
output filters:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49369
Brian, does
On 28 Aug 2009, at 06:13, toki...@aol.com wrote:
Brian Akins of Turner Broadcasting, Inc. wrote...
We are moving towards the 'if you say you support gzip,
then you get gzip' attitude.
The only approach that makes sense. Good to hear that from
folks as big as you.
There isn't a
MIME types.
That's a complete separate discussion and I'm not
goint to 'go there' tonight.
-Original Message-
From: William A. Rowe, Jr. wr...@rowe-clan.net
To: dev@httpd.apache.org dev@httpd.apache.org
Sent: Wed, Aug 26, 2009 1:47 pm
Subject: mod_cache, mod_deflate and Vary: User-Agent
On 8/26/09 3:20 PM, Paul Querna p...@querna.org wrote:
I would write little lua scriptlets that map user agents to two
buckets: supports gzip, doesnt support gzip. store the thing in
mod_cache only twice, instead of once for every user agent.
We do the same basic thing. We are moving
, Aug 27, 2009 9:42 am
Subject: Re: mod_cache, mod_deflate and Vary: User-Agent
On 8/26/09 3:20 PM, Paul Querna p...@querna.org wrote:
I would write little lua scriptlets that map user agents to two
buckets: supports gzip, doesnt support gzip. store the thing in
mod_cache only twice
On Wed, Aug 26, 2009 at 11:47 AM, William A. Rowe,
Jr.wr...@rowe-clan.net wrote:
I think we blew it :)
Vary: user-agent is not practical for correcting errant browser behavior.
For example;
User-Agent: Mozilla/5.0 Gecko/20090729 Firefox/3.5.2
produces a myriad number of 'variant' flavors
Paul Querna wrote:
Yes, write a Varied header to 'hash' plugin API for mod_cache.
I would write little lua scriptlets that map user agents to two
buckets: supports gzip, doesnt support gzip. store the thing in
mod_cache only twice, instead of once for every user agent.
This doesn't solve
On Wed, Aug 26, 2009 at 2:50 PM, William A. Rowe,
Jr.wr...@rowe-clan.net wrote:
Paul Querna wrote:
Yes, write a Varied header to 'hash' plugin API for mod_cache.
I would write little lua scriptlets that map user agents to two
buckets: supports gzip, doesnt support gzip. store the thing in
I don't understand why standard mod_deflate functionality won't work.
If you violate the specs and muck with content-length, it's not going to
work right in a browser, anyhow.
Thanks,
Rick Houser
Auto-Owners Insurance
Systems Support
(517)703-2580
-Original Message-
From: Anthony J
We're not violating the specs, we're following them. The HTTP spec
states that you should send out a content-length header with the correct
trasnfer length, and mod_deflate in this case is not doing that.
-Tony
---
Manager, IT Operations
Format Dynamics, Inc.
303-573
On Thu, Jul 16, 2009 at 00:39, Anthony J.
Biaccoabia...@formatdynamics.com wrote:
I'm trying to use mod_deflate to compress data coming out of tomcat
through mod_jk and need the proper content-length header set for the
COMPRESSED data, but can't do this because the data is streamed and sent
Looks like this got lost in the ether ...
Begin forwarded message:
On 15 Jul 2009, at 23:39, Anthony J. Biacco wrote:
I'm trying to use mod_deflate to compress data coming out of tomcat
through mod_jk and need the proper content-length header set for the
COMPRESSED data, but can't do
: RE: mod_deflate feature needed
I can get the compressed content, that's not a problem. My thing is, I'm
trying to cache said response at my CDN. The CDN requires a
content-length header (among other things) to do this. And with the
chunked encoding I'm not getting one (fyi, I'm not doing chunked
On Thu, 2009-07-16 at 10:20 -0600, Anthony J. Biacco wrote:
We're not violating the specs, we're following them. The HTTP spec
states that you should send out a content-length header with the correct
trasnfer length, and mod_deflate in this case is not doing that.
-Tony
No it doesn't
Subject: RE: mod_deflate feature needed
I'm not familiar with the CDN acronym. I could be mistaken, but I'm
fairly certain that HTTP 1.1 required support for chunked transfer
(which implies Content-Length would NOT be required for anything HTTP
1.1 compliant). Additionally, I thought
: mod_deflate feature needed
Looks like this got lost in the ether ...
Begin forwarded message:
On 15 Jul 2009, at 23:39, Anthony J. Biacco wrote:
I'm trying to use mod_deflate to compress data coming out of tomcat
through mod_jk and need the proper content-length header set
-Original Message-
From: Anthony J. Biacco [mailto:abia...@formatdynamics.com]
Sent: Thursday, July 16, 2009 1:16 PM
To: modules-...@httpd.apache.org
Subject: RE: mod_deflate feature needed
Yep, that's what I said, should. It doesn't require it and I
understand
why I's chunking
I'm trying to use mod_deflate to compress data coming out of tomcat
through mod_jk and need the proper content-length header set for the
COMPRESSED data, but can't do this because the data is streamed and sent
after the headers are set, therefore we don't know the compressed
content-length until
On Tue, Jul 14, 2009 at 05:47:16PM +0200, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: William A. Rowe, Jr.
Sent: Montag, 13. Juli 2009 23:58
To: dev@httpd.apache.org
Subject: Re: mod_deflate DoS using HEAD
Nick Kew wrote:
Eric Covener wrote
Joe Orton wrote:
I'm confused. Why do this check so late, and why does r-bytes_sent
matter? Why does it screw up the protocol if the DEFLATE filter does
nothing for a HEAD request? Because of the concern that a HEAD will
return a different C-L C-E to a GET on the same resource with
-Original Message-
From: Joe Orton [mailto:jor...@redhat.com]
Sent: Mittwoch, 15. Juli 2009 09:51
To: dev@httpd.apache.org
Subject: Re: mod_deflate DoS using HEAD
On Tue, Jul 14, 2009 at 05:47:16PM +0200, Plüm, Rüdiger,
VF-Group wrote:
-Original Message
William A. Rowe, Jr. wr...@rowe-clan.net writes:
Joe Orton wrote:
Does 2616 mandate that a resource must always
exactly the same set of content-codings across methods and time?
(AFAICT there is no MUST on that front; it's a SHOULD if anything)
Read through to the end, it breaks all
On Wed, Jul 15, 2009 at 11:03:24AM +0200, Plüm, Rüdiger, VF-Group wrote:
I'm confused. Why do this check so late, and why does r-bytes_sent
matter? Why does it screw up the protocol if the DEFLATE
All depends on the first brigade that passes mod_deflate. If this brigade
contains
-Original Message-
From: Joe Orton [mailto:jor...@redhat.com]
Sent: Mittwoch, 15. Juli 2009 15:29
To: dev@httpd.apache.org
Subject: Re: mod_deflate DoS using HEAD
On Wed, Jul 15, 2009 at 11:03:24AM +0200, Plüm, Rüdiger,
VF-Group wrote:
I'm confused. Why do this check so
On Tue, Jul 14, 2009 at 11:47 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
All very true. But how about the following patch. It should do no
harm and should solve the issue in at least some cases (I think
in most cases):
Index: modules/filters/mod_deflate.c
+if
Joe Orton wrote:
On Wed, Jul 15, 2009 at 11:03:24AM +0200, Plüm, Rüdiger, VF-Group wrote:
I'm confused. Why do this check so late, and why does r-bytes_sent
matter? Why does it screw up the protocol if the DEFLATE
All depends on the first brigade that passes mod_deflate. If this brigade
William A. Rowe, Jr. wrote:
So +1 to the proposed patch; in fact, +1 on unsetting C-L and treating
HEAD to the same processing as 304.
+1. Since it's a SHOULD not a MUST, we can be pragmatic
with the headers.
That's back to Eric's original patch, isn't it?
--
Nick Kew
-Original Message-
From: William A. Rowe, Jr.
Sent: Montag, 13. Juli 2009 23:58
To: dev@httpd.apache.org
Subject: Re: mod_deflate DoS using HEAD
Nick Kew wrote:
Eric Covener wrote:
/* For a 304 response, only change the headers */
-if (r-status
Plüm, Rüdiger, VF-Group wrote:
+/*
+ * Optimization: If we are a HEAD request and bytes_sent is not zero
+ * it means that we have passed the content-length filter once and
+ * have more data to sent. This means that the content-length filter
+ *
William A. Rowe, Jr. wrote:
Plüm, Rüdiger, VF-Group wrote:
+/*
+ * Optimization: If we are a HEAD request and bytes_sent is not zero
+ * it means that we have passed the content-length filter once and
+ * have more data to sent. This means that the
Nick Kew wrote:
The content-length could've been set anyway - the simplest case being
a static file that's been stated. Have we definitely unset it?
D'oh. Of course we have.
Is this really an optimization? Sounds like correctness :) And do we
want
to also validate that Accept-Encoding:
On Jul 14, 2009, at 10:02 AM, Nick Kew wrote:
That, on the other hand, stands. In the case of an HTTP/1.0
request, we'd be closing the connection to signal end-of-response.
Not on a HEAD request.
Roy
Roy T. Fielding wrote:
On Jul 14, 2009, at 10:02 AM, Nick Kew wrote:
That, on the other hand, stands. In the case of an HTTP/1.0
request, we'd be closing the connection to signal end-of-response.
Not on a HEAD request.
But on the GET request with the deflate filter installed, we would not
Eric Covener wrote:
/* For a 304 response, only change the headers */
-if (r-status == HTTP_NOT_MODIFIED) {
+if (r-status == HTTP_NOT_MODIFIED || r-header_only) {
Technically speaking, screws up the protocol.
IMHO it would be acceptable provided:
(a) it's an option
Nick Kew wrote:
Eric Covener wrote:
/* For a 304 response, only change the headers */
-if (r-status == HTTP_NOT_MODIFIED) {
+if (r-status == HTTP_NOT_MODIFIED || r-header_only) {
Technically speaking, screws up the protocol.
IMHO it would be acceptable
William A. Rowe, Jr. wrote:
* do not do server-side deflation (it is expensive).
Whoops - forgot one more
* do not do content deflation, only transfer deflation, which
should not metered by the content-length, right?
On Sun, Jun 28, 2009 at 08:20:20PM +0200, Stefan Fritsch wrote:
we have received a bug report [1] that a DoS is possible with
mod_deflate since it does not stop to compress large files even after
the network connection has been closed. This allows to use large
amounts of CPU
Hi,
we have received a bug report [1] that a DoS is possible with
mod_deflate since it does not stop to compress large files even after
the network connection has been closed. This allows to use large
amounts of CPU if there is a largish (10 MB) file available that has
mod_deflate enabled
On tis, 2008-04-29 at 09:42 +0200, André Malo wrote:
Just to be exact - it *might* vary, depending on how no-gzip is set.
But then most likely not based on Accept-Encoding but other headers such
as User-Agent or the source IP...
In any event I fully agree that it's then the responsibility of
I would like to propose a change to mod_deflate that would still send
the Vary header if the request is flagged with no-gzip or gzip-only-
text/html.
I think the checks for Content-Range and Content-Encoding should be
done, then the Vary header should be set and then the checks
On Mon, 28 Apr 2008 15:10:14 -0400
Brian J. France [EMAIL PROTECTED] wrote:
I would like to propose a change to mod_deflate that would still
send the Vary header if the request is flagged with no-gzip or
gzip-only- text/html.
But if no-gzip is set, then the response will not be compressed
to recent discussion, in particular
http://marc.info/?l=apache-httpd-devm=118622934222115w=2
and take a look at mod_deflate in /trunk/ and STATUS in 2.2.
Any thoughts there?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
).
Please refer to recent discussion, in particular
http://marc.info/?l=apache-httpd-devm=118622934222115w=2
and take a look at mod_deflate in /trunk/ and STATUS in 2.2.
Any thoughts there
Thanks for the pointers; I wasn't sure what was worth reading ;)
I generally agree with you
Right now the inflate filter only checks to see if the Content-Encoding
in the headers table contains gzip. It does not check
r-content_encoding. This breaks it with mod_mime (among other things).
The fix is straightforward enough, and I've attached a patch to the bug.
I've tested it to (try to)
On 7/4/07, Marco Spinetti [EMAIL PROTECTED] wrote:
So are you telling me that I should call deflate_in_filter (which is
defined inside mod_defalte) inside my module and then go on with the
uncompressed result?
Could you give me some suggestion about how to do it?
you need to include mod_deflate
need to include mod_deflate in config:
LoadModule mod_deflate
then in function where you call hooks you need to put this function:
ap_add_output_filter(INFLATE, ctx, req, conn);
and you'll have inflate filter right before your own. chekc docs for
proper usage and parameters.
module my_module
to
pass it to mod_deflate, which decompresses it, and then elaborate it
with the other sources.
Nick, could you advice me with a solution (the only solution I'm seeing
now is write a function to decompress the content but I'd like to use
the one given by mod_deflate).
Nick Kew ha scritto
as the mod_deflate code
is a usage example.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
I have a question about how to use a part of mod_deflate in my module.
Inside my module I connect to a external source sending it a dynamic
query and it replies with a gzip content.
I should take this content, decompress it and then I have to modify it.
I'd like to know if inside my module I
101 - 200 of 460 matches
Mail list logo
