Re: [PATCH] mod_deflate: remove filter after seeing EOS

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

Re: [PATCH] mod_deflate: remove filter after seeing EOS

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

Re: [PATCH] mod_deflate: remove filter after seeing EOS

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

Re: [PATCH] mod_deflate: remove filter after seeing EOS

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

Re: [PATCH] mod_deflate: remove filter after seeing EOS

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

Re: [PATCH] mod_deflate: remove filter after seeing EOS

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 >

Re: [PATCH] mod_deflate: remove filter after seeing EOS

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

Re: [PATCH] mod_deflate: remove filter after seeing EOS

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

Re: [PATCH] mod_deflate: remove filter after seeing EOS

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: >

Re: [PATCH] mod_deflate: remove filter after seeing EOS

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

Re: [PATCH] mod_deflate: remove filter after seeing EOS

/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

Re: [PATCH] mod_deflate: remove filter after seeing 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

Re: [PATCH] mod_deflate: remove filter after seeing EOS

> > 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

[PATCH] mod_deflate: remove filter after seeing EOS

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

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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,

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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:

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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 >

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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?

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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). >

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

[-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

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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

[PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

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

Re: Unbounded memory usage in mod_dav + mod_headers/mod_deflate/...

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)

Re: Unbounded memory usage in mod_dav + mod_headers/mod_deflate/...

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

Re: Unbounded memory usage in mod_dav + mod_headers/mod_deflate/...

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

Re: Unbounded memory usage in mod_dav + mod_headers/mod_deflate/...

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

Re: Unbounded memory usage in mod_dav + mod_headers/mod_deflate/...

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.,

Re: Unbounded memory usage in mod_dav + mod_headers/mod_deflate/...

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 */ >

Unbounded memory usage in mod_dav + mod_headers/mod_deflate/...

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

Re: [PATCH 54255] mod_deflate adjusts the headers "too late"

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

[PATCH 54255] mod_deflate adjusts the headers "too late"

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

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

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

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

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!

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

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

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

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) :

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

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

mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

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'

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

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

Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA

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?

Custom modules : what's the behavior of mod_deflate ?

(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

Re: Custom modules : what's the behavior of mod_deflate ?

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

Re: Custom modules : what's the behavior of mod_deflate ?

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.

Many test failures on mod_deflate tests

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

Re: Many test failures on mod_deflate tests

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

Re: Many test failures on mod_deflate tests

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

Re: output filter ordering question: mod_deflate vs mod_headers vs mod_pagespeed

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

Re: output filter ordering question: mod_deflate vs mod_headers vs mod_pagespeed

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

output filter ordering question: mod_deflate vs mod_headers vs mod_pagespeed

(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

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… 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

RE: DoS with mod_deflate range requests

-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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

RE: DoS with mod_deflate range requests

-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

CVE (Was: DoS with mod_deflate range requests)

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

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. 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

CVE-2011-3192 (Was: CVE (Was: DoS with mod_deflate range requests))

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

RE: Mitigation Range header (Was: DoS with mod_deflate range requests)

-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

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 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

Re: 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

RE: Mitigation Range header (Was: DoS with mod_deflate range requests)

-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

RE: Mitigation Range header (Was: DoS with mod_deflate range requests)

-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

Re: Mitigation Range header (Was: DoS with mod_deflate range requests)

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

RE: Mitigation Range header (Was: DoS with mod_deflate range requests)

-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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

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 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

RE: DoS with mod_deflate range requests

-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

Re: DoS with mod_deflate range requests

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

RE: DoS with mod_deflate range requests

-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

RE: DoS with mod_deflate range requests

-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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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,

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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.

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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

Re: DoS with mod_deflate range requests

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   2   3   4   5   >