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
G/E,
httpd-trunk\modules\ssl\ssl_engine_config.c (164):
mctx-pkp-cert_file = NULL;
mctx-pkp-cert_path = NULL;
mctx-pkp-ca_cert_file = NULL
mctx-pkp-certs = NULL;
mctx-pkp-ca_certs = NULL;
Seems like there is a need of punctuation...
This one is trickier:
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
-Original Message-
From: NormW [mailto:no...@gknw.net]
Sent: Mittwoch, 24. August 2011 10:12
To: dev@httpd.apache.org
Subject: CT oops?
G/E,
httpd-trunk\modules\ssl\ssl_engine_config.c (164):
mctx-pkp-cert_file = NULL;
mctx-pkp-cert_path = NULL;
On 24/08/2011 6:42 PM, Plüm, Rüdiger, VF-Group wrote:
Fixed in r1161002.
Fixed in r1161005
Regards
Rüdiger
Confirm httpd-trunk now builds for NetWare without issue.
Thx.
Norm
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)
Comments please. Esp. on the quality and realisticness of the mitigtions.
Title: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and
Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all
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
1.3 and
Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled
* Plüm, Rüdiger, VF-Group:
As said this has *nothing* to do with mod_deflate. This was IMHO just
a guess by the original author of the tool.
This matches my testing, too. I see a significant peak in RAM usage on
a server where apachectl -M does not print anything with the string
deflate (so I
-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
On 24 Aug 2011, at 13:22, Florian Weimer wrote:
* Plüm, Rüdiger, VF-Group:
As said this has *nothing* to do with mod_deflate. This was IMHO just
a guess by the original author of the tool.
This matches my testing, too. I see a significant peak in RAM usage on
a server where apachectl
* Dirk-WIllem van Gulik:
Hmm - when I remove mod_deflate (i.e. explicitly as it is the default
in all our installs) and test on a / entry which is a static file
which is large (100k)* - then I cannot get apache on its knees on a
freebsd machine - saturating the 1Gbit connection it has (Note:
-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
On 24 Aug 2011, at 13:43, Florian Weimer wrote:
* Dirk-WIllem van Gulik:
Hmm - when I remove mod_deflate (i.e. explicitly as it is the default
in all our installs) and test on a / entry which is a static file
which is large (100k)* - then I cannot get apache on its knees on a
freebsd
-Original Message-
From: Dirk-WIllem van Gulik [mailto:di...@webweaving.org]
Sent: Mittwoch, 24. August 2011 14:40
To: dev@httpd.apache.org
Cc: Plüm, Rüdiger, VF-Group
Subject: Re: Mitigation Range header
On 24 Aug 2011, at 13:22, Florian Weimer wrote:
* Plüm, Rüdiger,
.
Title: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and
Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability
* Dirk-WIllem van Gulik:
On 24 Aug 2011, at 13:43, Florian Weimer wrote:
* Dirk-WIllem van Gulik:
Hmm - when I remove mod_deflate (i.e. explicitly as it is the default
in all our installs) and test on a / entry which is a static file
which is large (100k)* - then I cannot get apache on
On 24 Aug 2011, at 14:01, Plüm, Rüdiger, VF-Group wrote:
Have you tried if the same happens with mod_deflate, but with one of the
the proposed mitigations in place?
As soon as I reject/block on the range header - all is fine again.
As said my guess is that this might be an issue with
* Is this the right list (and order) of the mitigations - or should
ReWrite be first ?
FWIW I don't like rewrite first because it's so unruly with being
defined once per vhost + main server + RewriteEngine on.
I like RequestHeader simplicity, and could be combined with SetEnvIf
to only
: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and
Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found
On Wed, Aug 24, 2011 at 9:17 AM, Eric Covener cove...@gmail.com wrote:
* Is this the right list (and order) of the mitigations - or should
ReWrite be first ?
FWIW I don't like rewrite first because it's so unruly with being
defined once per vhost + main server + RewriteEngine on.
I
On Wed, Aug 24, 2011 at 9:29 AM, Eric Covener cove...@gmail.com wrote:
On Wed, Aug 24, 2011 at 9:17 AM, Eric Covener cove...@gmail.com wrote:
* Is this the right list (and order) of the mitigations - or should
ReWrite be first ?
FWIW I don't like rewrite first because it's so unruly
On Wed, Aug 24, 2011 at 9:01 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
Hmm - when I remove mod_deflate (i.e. explicitly as it is the
default in all our installs) and test on a / entry which is a
static file which is large (100k)* - then I cannot get apache
on its
-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}
and Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way
the multiple overlapping ranges
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Mittwoch, 24. August 2011 15:29
To: dev@httpd.apache.org
Subject: Re: CVE-2011-3192: Range header DoS vulnerability in
Apache 1.3 and Apache 2 (DRAFT-3)
On Wed, Aug 24, 2011 at 9:17 AM, Eric Covener
From: Greg Ames Sent: Mittwoch, 24. August 2011 16:05
To: dev@httpd.apache.org
Subject: Re: Mitigation Range header
On Wed, Aug 24, 2011 at 9:01 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
Dirk,
Am 24.08.2011 15:23, schrieb Dirk-WIllem van Gulik:
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
can you please apply:
--- mod_rangecnt.c.orig Wed Aug 24 16:25:34 2011
+++ mod_rangecnt.c Wed Aug 24
: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org
On 24 Aug 2011, at 15:34, Guenter Knauf wrote:
can you please apply:
--- mod_rangecnt.c.orig Wed Aug 24 16:25:34 2011
+++ mod_rangecnt.cWed Aug 24 15:26:48 2011
Done.
which I need on NetWare in order to get ap_hook_post_read_request() proto;
and maybe we should also add links
+1's on below - or feedback on what we'd
like to have changed ?
* Would like to get this out in an hour or so ?
* FIne with the 48 hours commitment of an update ?
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability
Apache HTTPD 1.3/2.x
Date: 20110824 1600Z
CustomLog logs/range.log %r %{Range}i env=bad-range
Actually I was only using that to show/debug the result of the
directives, did not occur that folks would also want to log these!
Of course that makes sense though.
Unfortunately we lose the range header in the log when we zap it, so
logging
Various suggest on-list and off-list fixes applied. Thanks all.
A few more +1's would be nice :)
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled
+1
On Aug 24, 2011, at 10:29 AM, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Mittwoch, 24. August 2011 15:29
To: dev@httpd.apache.org
Subject: Re: CVE-2011-3192: Range header DoS vulnerability in
Apache 1.3 and Apache
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache
On Wed, Aug 24, 2011 at 10:56 AM, Dirk-Willem van Gulik
di...@webweaving.org wrote:
+1 with Eric's edits. specifically,
1) Use mod_rewrite to limit the number of ranges:
Option 1 doesn't use mod_rewrite.
Option 1:
# drop Range header when more than 5 ranges.
#
Thanks for all the help. All fixes included. Below will go out to announce at
the top of the hour - unless I see a veto.
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD
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...
But
On Wed, Aug 24, 2011 at 10:33 AM, Plüm, Rüdiger, VF-Group
ruediger.pl...@vodafone.com wrote:
**
I think mod_deflate is just the tool to convert an O(N^2) data size problem
into an O(N^2) CPU usage problem, where N is some function of
LimitRequestLine. If the file size is smaller than the
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 the
From: Greg Ames [mailto:ames.g...@gmail.com]
Sent: Mittwoch, 24. August 2011 18:20
To: dev@httpd.apache.org
Subject: Re: Mitigation Range header
On Wed, Aug 24, 2011 at 10:33 AM, Plüm, Rüdiger,
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
I'm seeing Apache 2.0 doesn't accept our RequestHeader syntax due to a
defect, it misinterprets it as a value and fails startup.
If we have the opportunity to amend, I think we need to suggest the
rewrite flavor for Apache 2.0 and earlier, not just 1.3 and earlier.
Also for 1.3, is our RE safe
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 Wed, 24 Aug 2011 09:30:34 -0400
Eric Covener cove...@gmail.com wrote:
Or more like Ruedigers:
SetEnvIf Range (,[^,]*){5,} bad-range=1
Or just
Untaint HTTP_RANGE (,[^,]*){5,}
Is it time to re-suggest dropping mod_taint into trunk?
--
Nick Kew
That is fine - we can do another update tomorrow, say noon zulu - if we expect
that we do not have a proper patch and/or a 2.0.65 / 2.2.20 in the day
following.
Weird though - my 2.0.61 and 64 does seem fine. So probably very early 2.0
series.
Dw
On 24 Aug 2011, at 20:40, Eric Covener wrote:
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
AFAICS[1], we've discussed an advisory and some protections
users can deploy. For the future we should be looking at
a robust solution that prevents Range requests only when
they're likely to present a problem.
Most obviously, we should be able to serve arbitrary ranges
from any static or cached
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, Nick Kew wrote:
AFAICS[1], we've discussed an advisory and some protections
users can deploy. For the future we should be looking at
a robust solution that prevents Range requests only when
they're likely to present a problem.
Most obviously, we should be able to
On Wednesday 24 August 2011, Nick Kew wrote:
AFAICS[1], we've discussed an advisory and some protections
users can deploy. For the future we should be looking at
a robust solution that prevents Range requests only when
they're likely to present a problem.
Most obviously, we should be able
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
Hey everyone,
I don't like to bother mailing lists with beginner questions so I spent
a few hours on Google looking for info and tutorials. I'm sure at least one
of you has had that experience :) Anyway, I have finished my first module
and it works exactly how I want it to. I still have more
Rationale: allow me to search in my browser for 'W' (with quotes) to
find entries in the W state.
Patch (against trunk):
[[[
Index: modules/generators/mod_status.c
===
--- modules/generators/mod_status.c (revision 1161295)
+++
On Wed, Aug 24, 2011 at 5:16 PM, Stefan Fritsch s...@sfritsch.de wrote:
I have another idea: Instead of using apr_brigade_partition write a
new function ap_brigade_copy_part that leaves the original brigade
untouched. It would copy the necessary buckets to a new brigade and
then split the
On Thursday 25 August 2011, Greg Ames wrote:
On Wed, Aug 24, 2011 at 5:16 PM, Stefan Fritsch s...@sfritsch.de
wrote:
I have another idea: Instead of using apr_brigade_partition write
a new function ap_brigade_copy_part that leaves the original
brigade untouched. It would copy the necessary
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
vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping
94 matches
Mail list logo
