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
last chunk marker and before the EOS bucket (i.e. [crlf last-chunk
> > FLUSH EOS]), so there's no need for "userspace" to send an additional flush
> > after the EOS bucket, and so mod_deflate wouldn't complain. Does that sound
> > right?
>
> I don't think the m
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
>
tten it here:
> https://github.com/ericnorris/httpd/commit/5f8fa24786b937ab611160b3c765cededa6dcb12,
> though in retrospect I'm not sure why this (or your patch) alone isn't
> enough, and why I thought the mod_deflate patch was also needed.
In the repro case you posted, only one brigade is
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
/5f8fa24786b937ab611160b3c765cededa6dcb12,
though in retrospect I'm not sure why this (or your patch) alone isn't
enough, and why I thought the mod_deflate patch was also needed.
If I understand correctly, either patch would send the flush bucket after
the last chunk marker and before the EOS bucket (i.e. [crlf last-chunk
FLUSH EOS
veloped a proof-of-concept patch that
> > sent an EOS bucket and a flush bucket via a "userland" PHP function, we
> > were surprised that it didn't work when compression was enabled for the
> > request.
> >
> > I was able to reproduce this behavior with a
>
> I was able to reproduce this behavior with a simple Apache module built
> on top of mod_example_hooks:
>
> https://gist.github.com/ericnorris/37c7dac401b50d270867e82a47bdd294
>
> It seems that this is because mod_deflate receives the EOS bucket and
> then calls `deflateE
reproduce this behavior with a simple Apache module built
on top of mod_example_hooks:
https://gist.github.com/ericnorris/37c7dac401b50d270867e82a47bdd294
It seems that this is because mod_deflate receives the EOS bucket and
then calls `deflateEnd` but remains in the filter chain. This means that
it receive
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?
al_in; /* total nb of input bytes read so far */
> > [...]
> > z_off_t total_out; /* total nb of bytes output so far */
> > [...]
> > } z_stream;
>
> Ouch.
>
> >
> > This looks like an OpenBSD-specific change though (diff below).
>
ut; /* total nb of bytes output so far */
> [...]
> } z_stream;
Ouch.
>
> This looks like an OpenBSD-specific change though (diff below).
> I guess this will force OpenBSD to carry a local patch for
> mod_deflate then, or just compile without -Werror.
I think we need a bit of
[-Werror,-Wformat]
ctx->stream.total_in, ctx->stream.total_out, r->uri);
^
7 errors generated.
This looks like an OpenBSD-specific change though (diff below).
I gue
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
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?
Index: modules/filters/mod_deflate.c
Evgeny Kotkov writes:
> However, the problem I described in this thread is different, and it just
> happens to have the same visible consequence.
>
> What is probably more important, the dav_send_one_response() function
> that has the flaw (see the proposed patch)
Christophe JAILLET writes:
> Hi,
>
> while looking at some memory consumption issue in mod_dav, you can also
> have a look at the proposed patches in :
> https://bz.apache.org/bugzilla/show_bug.cgi?id=48130
>
> Definitively not the same approach, but the same
Le 29/08/2016 à 18:12, Evgeny Kotkov a écrit :
Evgeny Kotkov writes:
It might be possible to rework mod_dav_svn, although it's going to take
some time. Currently, every top-level handler receives an `ap_filter_t *`
and passes it further, and all these places
Evgeny Kotkov writes:
> It might be possible to rework mod_dav_svn, although it's going to take
> some time. Currently, every top-level handler receives an `ap_filter_t *`
> and passes it further, and all these places would have to be updated so
> that the actual
sage or incorrect
behavior in a routine that sends 's to the output filters.
The dav_send_one_response() function accepts the current head of the output
filter list as an argument, but the actual head can change between calls to
ap_pass_brigade(). This can happen with self-removing filters, e.g.,
On Fri, Aug 19, 2016 at 04:44:21PM +0300, Evgeny Kotkov wrote:
...
> The problem is caused by how mod_dav passes the output filter list to its
> providers. Please see the deliver() hook definition in mod_dav.h:1948 and
> its usage in mod_dav.c:888:
>
> /* Repository provider hooks */
>
We (as the Apache Subversion developers) have discovered that mod_dav can
trigger an unbounded memory usage when used in conjunction with a module that
inserts an output filter — such as mod_headers or mod_deflate. Below is the
configuration that can be used to reproduce the issue:
MaxMemFree
Keep in mind that such changes alter the expected behavior that all of the
third party module authors have worked around. This doesn't seem like
a suitable change for 2.4.x maintenance branch but a good improvement
for trunk, looking forwards.
On Tue, May 3, 2016 at 9:42 AM, Michael Kaufmann
Hi,
It would be great if somebody could have a look at the proposed patch.
The problem: Request headers are adjusted too late (in the input filter).
Proposed solution: Adjust the request headers in the filter init function.
https://bz.apache.org/bugzilla/show_bug.cgi?id=54255
Regards,
Michael
On Fri, Jun 5, 2015 at 1:05 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:
On Fri, Jun 5, 2015 at 12:42 AM, Christophe JAILLET
christophe.jail...@wanadoo.fr wrote:
This has been fixed in trunk in r1619453. ( APLOGNO(02805) )
Would you propose the backport? TIA!
And... I see you did
On Fri, Jun 5, 2015 at 12:42 AM, Christophe JAILLET
christophe.jail...@wanadoo.fr wrote:
This has been fixed in trunk in r1619453. ( APLOGNO(02805) )
Would you propose the backport? TIA!
I'm not compiling -Wall... so
/opt/apr15/build-1/libtool --silent --mode=compile gcc -std=gnu99
-I/usr/include/libxml2 -g -O2 -pthread -DLINUX -D_REENTRANT
-D_GNU_SOURCE -I. -I/home/wrowe/dev/httpd-2.4/os/unix
-I/home/wrowe/dev/httpd-2.4/include -I/opt/apr15/include/apr-1
On 06/05/2015 07:01 AM, William A Rowe Jr wrote:
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith g...@gknw.net
mailto:g...@gknw.net wrote:
This is new, not quite sure how I didn't see it a few weeks ago as
it's 9 weeks old.
Who forgot to fill in the number?
mod_deflate.c(1283) :
On 6/4/2015 10:01 PM, William A Rowe Jr wrote:
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smithg...@gknw.net wrote:
This is new, not quite sure how I didn't see it a few weeks ago as it's 9
weeks old.
Who forgot to fill in the number?
mod_deflate.c(1283) : warning C4003: not enough actual
This is new, not quite sure how I didn't see it a few weeks ago as it's
9 weeks old.
Who forgot to fill in the number?
mod_deflate.c(1283) : warning C4003: not enough actual parameters for
macro 'APLOGNO'
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith g...@gknw.net wrote:
This is new, not quite sure how I didn't see it a few weeks ago as it's 9
weeks old.
Who forgot to fill in the number?
mod_deflate.c(1283) : warning C4003: not enough actual parameters for
macro 'APLOGNO'
I just rechecked
Le 05/06/2015 07:11, Gregg Smith a écrit :
On 6/4/2015 10:01 PM, William A Rowe Jr wrote:
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smithg...@gknw.net wrote:
This is new, not quite sure how I didn't see it a few weeks ago as
it's 9
weeks old.
Who forgot to fill in the number?
(cross-posted on SO: http://stackoverflow.com/questions/24486594 )
I wrote a custom module for as described in:
http://httpd.apache.org/docs/2.4/developer/modguide.html
ap_rprintf(r, Hello, world!);
I've been asked about the behavior of mod_deflate
http://httpd.apache.org/docs/2.2/mod
By default, it would be compressed if it met the normal conditions.
You can opt out a few ways (below in rough order of intrusiveness):
set the no-gzip per-request environment variable (r-subprocess_env)
remove the mod_deflate output filter (mod_proxy_wstunnel.c has an
example of moving a filter
On 06/30/2014 12:18 PM, Eric Covener wrote:
By default, it would be compressed if it met the normal conditions.
You can opt out a few ways (below in rough order of intrusiveness):
thank you Eric.
I see many tests for mod_deflate currently failing on trunk (OS is RH5 64 Bit).
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/modules/deflate.t 47 33 70.21% 2-4 6-8 10-12 14-16
On 25.07.2013 13:43, Plüm, Rüdiger, Vodafone Group wrote:
I see many tests for mod_deflate currently failing on trunk (OS is RH5 64
Bit).
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t
On 25.07.2013 14:55, Rainer Jung wrote:
On 25.07.2013 13:43, Plüm, Rüdiger, Vodafone Group wrote:
I see many tests for mod_deflate currently failing on trunk (OS is RH5 64
Bit).
Failed Test Stat Wstat Total Fail Failed List of Failed
Thanks for the quick reply, Nick. I played around with this idea but
couldn't get it to work. My filter now runs at
AP_FTYPE_CONTENT_SET + 1, to make sure it runs after mod_headers. I don't
know how to try to coax mod_deflate to run after me. I can prevent it from
running before me by removing
sure it runs after mod_headers. I don't
know how to try to coax mod_deflate to run after me. I can prevent it from
running before me by removing it from the filter-chain in before my main
filter-function runs, but when I try to then put it back in the filter
chain after my main filter function
(deflateFilterName, deflate_out_filter, NULL,
AP_FTYPE_CONTENT_SET);
mod_pagespeed really needs to run before mod_deflate. mod_pagespeed needs
HTML in the clear, and we don't want to spend CPU-cycles re-inflating what
mod_deflate just shrunk.
But I'm at a loss
On Thursday 25 August 2011, Jim Jagielski wrote:
OK then… we seem to be coalescing into some consensus here…
basically, if the client sends stuff which is brain-dead stupid,
we simply 2000 and send the whole kit-and-kaboodle.
I'd like to propose that we update the byterange filter to perform
-Original Message-
From: Stefan Fritsch
Sent: Donnerstag, 25. August 2011 08:21
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range requests
On Thursday 25 August 2011, Jim Jagielski wrote:
OK then... we seem to be coalescing into some consensus here
On Aug 25, 2011, at 2:56 AM, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Stefan Fritsch
Sent: Donnerstag, 25. August 2011 08:21
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range requests
On Thursday 25 August 2011, Jim Jagielski wrote:
OK
On Wednesday 24 August 2011, Roy T. Fielding wrote:
My suggestion is to reject any request with overlapping ranges or
more than five ranges with a 416, and to send 200 for any request
with 4-5 ranges. There is simply no need to support random access
in HTTP.
Even with WebDAV?
BTW, I think
-Original Message-
From: Stefan Fritsch
Sent: Mittwoch, 24. August 2011 00:28
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range requests
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
Folks,
Have we done (or who is doing a CVE) on this ? So we get immediate 'fixes' out
like a tiny patch to count the comma's, a caveated LimitRequestFieldSize 100 or
a clever Regex on %{HTTP_Range}.
Or am I totally asleep and missed the CVE (as my google foo only nets me
CVE-2005-2728 right
Folks,
This issue is now active in the wild. So some unified/simple comms is needed.
What is the wisdom on mitigation advise/briefing until a proper fix it out - in
order of ease:
- Where possible - disable mod_deflate
= we sure this covers all cases - or this is a good
The new Range: header has been given the CVE of
CVE-2011-3192
Please use that in subjects, commits and what not.
Thanks,
Dw.
On 24 Aug 2011, at 09:28, Dirk-Willem van Gulik wrote:
Folks,
Have we done (or who is doing a CVE) on this ? So we get immediate 'fixes'
out like a tiny
-Original Message-
From: Dirk-Willem van Gulik
Sent: Mittwoch, 24. August 2011 13:33
To: dev@httpd.apache.org
Subject: Mitigation Range header (Was: DoS with mod_deflate
range requests)
Folks,
This issue is now active in the wild. So some unified/simple
comms is needed
On Wed, Aug 24, 2011 at 7:57 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
-Original Message-
From: Dirk-Willem van Gulik
Sent: Mittwoch, 24. August 2011 13:33
To: dev@httpd.apache.org
Subject: Mitigation Range header (Was: DoS with mod_deflate
range requests
On 24 Aug 2011, at 12:57, Plüm, Rüdiger, VF-Group wrote:
- Where possible - disable mod_deflate
= we sure this covers all cases - or this is a good stopgap ?
As said this has *nothing* to do with mod_deflate. This was IMHO just
a guess by the original author of the tool.
Ok
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Mittwoch, 24. August 2011 14:05
To: dev@httpd.apache.org
Subject: Re: Mitigation Range header (Was: DoS with
mod_deflate range requests)
On Wed, Aug 24, 2011 at 7:57 AM, Plüm, Rüdiger, VF-Group
-Original Message-
From: Dirk-Willem van Gulik [mailto:di...@webweaving.org]
Sent: Mittwoch, 24. August 2011 14:14
To: dev@httpd.apache.org
Subject: Re: Mitigation Range header (Was: DoS with
mod_deflate range requests)
On 24 Aug 2011, at 12:57, Plüm, Rüdiger, VF-Group
Of course it should have been:
RewriteCond %{HTTP:range} !^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* - [F]
The problem with the negation is you need an addl rule to handle an
empty range header, this would forbid normal non-range requests.
--
Eric Covener
cove...@gmail.com
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Mittwoch, 24. August 2011 14:59
To: dev@httpd.apache.org
Subject: Re: Mitigation Range header (Was: DoS with
mod_deflate range requests)
Of course it should have been:
RewriteCond %{HTTP:range
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 in the
request.
My suggestion is to reject any request with overlapping ranges or more
than five
On Aug 23, 2011, at 9:34 PM, Roy T. Fielding wrote:
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
On 24 Aug 2011, at 16:35, 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 in the
request.
My suggestion is to reject any
On Aug 24, 2011, at 4:05 AM, Plüm, Rüdiger, VF-Group wrote:
Patch looks good, but some comments:
As far as I can see the following range request would not get merged:
Range: bytes=0-0,1-1,2-2
into a 0-2 range as need_sort would remain 0. OTOH
Range: bytes=0-0,0-1,1-2
would get
-Original Message-
From: Dirk-Willem van Gulik [mailto:dirk-willem.van.gu...@bbc.co.uk]
Sent: Mittwoch, 24. August 2011 17:46
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range requests
On 24 Aug 2011, at 16:35, Tim Bannister wrote:
On Tue, Aug 23, 2011
Sorting isn't allowed but I get the impression that merging is OK…
Roy can confirm…
If not, then some sort of runtime limit on the number of allowable
ranges plus a 416 w/ overlapping ranges makes the most sense.
On Aug 24, 2011, at 11:55 AM, Plüm, Rüdiger, VF-Group wrote:
Hm. If I got it
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Mittwoch, 24. August 2011 17:48
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range requests
On Aug 24, 2011, at 4:05 AM, Plüm, Rüdiger, VF-Group wrote:
Patch looks good, but some
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Mittwoch, 24. August 2011 18:02
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range requests
Sorting isn't allowed but I get the impression that merging is OK...
Roy can confirm
On 8/24/2011 10:55 AM, Plüm, Rüdiger, VF-Group wrote:
Hm. If I got it right what Roy says above about the spec sorting and merging
is
not an option as we need to stick to the order and number of ranges the client
requested.
No. Merging -is- recommended.
10.4.17 416 Requested Range Not
On Aug 24, 2011, at 12:05 PM, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Mittwoch, 24. August 2011 18:02
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range requests
Sorting isn't allowed but I get
On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote:
0-, 40-50 becomes 0-
0-499, 400-599 becomes 0-599
1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250
This goes against Roy's recommendation to 416 overlaps… But
I do see that an overlap is specifically noted in an example
On Wednesday 24 August 2011, Jim Jagielski wrote:
On Aug 24, 2011, at 12:05 PM, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Mittwoch, 24. August 2011 18:02
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range
On 24 Aug 2011, at 17:47, Stefan Fritsch wrote:
On Wednesday 24 August 2011, Jim Jagielski wrote:
On Aug 24, 2011, at 12:05 PM, Plüm, Rüdiger, VF-Group wrote:
But merging might require sorting...
then we don't do that merge, imo… In other words, we progress thru the set
of ranges and once
On Wed, Aug 24, 2011 at 12:42 PM, Jim Jagielski j...@jagunet.com wrote:
On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote:
0-, 40-50 becomes 0-
0-499, 400-599 becomes 0-599
1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250
This goes against Roy's recommendation to
On Aug 24, 2011, at 2:43 PM, Tim Bannister wrote:
On 24 Aug 2011, at 17:47, Stefan Fritsch wrote:
On Wednesday 24 August 2011, Jim Jagielski wrote:
On Aug 24, 2011, at 12:05 PM, Plüm, Rüdiger, VF-Group wrote:
But merging might require sorting...
then we don't do that merge, imo… In
On Aug 24, 2011, at 3:10 PM, Greg Ames wrote:
On Wed, Aug 24, 2011 at 12:42 PM, Jim Jagielski j...@jagunet.com wrote:
From the above, I would be more comfortable with
0-, 40-50 --- 0-
0-499, 400-599 --- 0-599
1000-1075, 1025-1088, 200-250, 1051-1100 -- 1000-1088, 200-250,
On 8/24/2011 11:42 AM, Jim Jagielski wrote:
On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote:
0-, 40-50 becomes 0-
0-499, 400-599 becomes 0-599
1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250
This goes against Roy's recommendation to 416 overlaps… But
I do see
On Aug 24, 2011, at 3:34 PM, William A. Rowe Jr. wrote:
On 8/24/2011 11:42 AM, Jim Jagielski wrote:
On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote:
0-, 40-50 becomes 0-
0-499, 400-599 becomes 0-599
1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250
This goes
On 24 Aug 2011, at 20:13, Jim Jagielski wrote:
Another option is just to return 200. Servers MAY ignore the Range header. I
prefer this because existing clients already handle that case well, and
there's no opportunity for a client to exploit this (“malicious” clients
that want the whole
On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski j...@jagunet.com wrote:
If we only merge adjacent ascending ranges, then it seems like an
attacker could just craft a header where the ranges jump around and dodge
our fix.
I think no matter what, we should still have some sort of
upper
On 24 Aug 2011, at 21:39, Greg Ames wrote:
On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski j...@jagunet.com wrote:
If we only merge adjacent ascending ranges, then it seems like an attacker
could just craft a header where the ranges jump around and dodge our fix.
I think no matter
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 in the
request.
My suggestion is to reject any
On Aug 24, 2011, at 8:55 AM, Plüm, Rüdiger, VF-Group wrote:
Hm. If I got it right what Roy says above about the spec sorting and merging
is
not an option as we need to stick to the order and number of ranges the client
requested. But we can deny overlapping with a 416.
We should implement
On 8/24/2011 3:45 PM, Dirk-WIllem van Gulik wrote:
On 24 Aug 2011, at 21:39, Greg Ames wrote:
On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski j...@jagunet.com
mailto:j...@jagunet.com wrote:
If we only merge adjacent ascending ranges, then it seems like an
attacker could
On 8/24/2011 3:12 PM, Jim Jagielski wrote:
On Aug 24, 2011, at 3:34 PM, William A. Rowe Jr. wrote:
On 8/24/2011 11:42 AM, Jim Jagielski wrote:
On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote:
0-, 40-50 becomes 0-
0-499, 400-599 becomes 0-599
1000-1075, 200-250, 1051-1100
On Wednesday 24 August 2011, Dirk-WIllem van Gulik wrote:
I think no matter what, we should still have some sort of
upper limit on the number of range-sets we accept… after all,
merge doesn't prevent jumping around ;)
The problem I have with the upper limit on the number of range
I'm cool w/ that… treat non-ascending ranges as potential hinky
and count those and only allow a certain number of them…
Still not sure if we should count overlaps as bad or not…
that RFC example troubles me:
14.35.1 Byte Ranges
- Several legal but not canonical specifications of the
On Aug 24, 2011, at 5:00 PM, William A. Rowe Jr. wrote:
At least, after 256 ranges or so, fall back to a 200 response in lieu of
a 400/416 response.
+1 on not sending 416 if we hit some limit and fall back on 200.
On 8/24/2011 3: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 in the
On 8/24/2011 4:06 PM, Jim Jagielski wrote:
I'm cool w/ that… treat non-ascending ranges as potential hinky
and count those and only allow a certain number of them…
Still not sure if we should count overlaps as bad or not…
that RFC example troubles me:
14.35.1 Byte Ranges
- Several
On Wed, Aug 24, 2011 at 5:06 PM, Jim Jagielski j...@jagunet.com wrote:
I'm cool w/ that… treat non-ascending ranges as potential hinky
and count those and only allow a certain number of them…
Still not sure if we should count overlaps as bad or not…
that RFC example troubles me:
14.35.1
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 the reason we have an Apache server is to
1 - 100 of 460 matches
Mail list logo