On 9/5/2011 3:08 AM, Gregg L. Smith wrote:
>
> regressions suck, but the killer is silenced as far as I can tell at this
> point, the
> script fails it's internal test, no need to rush and gain more regressions
> hurrying to fix
> the regressions from hurrying to silence the killer. My meager vi
On 9/5/2011 8:21 AM, Joe Orton wrote:
>
> => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
>
> Is there consensus to treat the issues described there as not being
> security-sensitive? If so we can probably put tihs on the vulnerability
> list is as a not-a-bug as an "official st
On Tue, Sep 6, 2011 at 9:32 AM, Jim Jagielski wrote:
>
> On Sep 6, 2011, at 8:41 AM, Eric Covener wrote:
>
>> On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen wrote:
e.g. MaxRanges none | 0 (none) | unlimited | n>=1
>>> 0 means unlimited - this is consistent across all of our configuration
>>> di
On Sun, Sep 4, 2011 at 7:26 PM, William A. Rowe Jr. wrote:
> On 9/3/2011 2:49 PM, Jeff Trawick wrote:
>>
>> With this fix, I get no testcase failures and this skippage:
>
> Bingo, stared at that code for hours, finally realized I had
> re-extracted a -2.2 labeled patch instead of correcting the -2
On Sep 6, 2011, at 8:41 AM, Eric Covener wrote:
> On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen wrote:
>>> e.g. MaxRanges none | 0 (none) | unlimited | n>=1
>> 0 means unlimited - this is consistent across all of our configuration
>> directives. Please let's not change that here. It's what folks e
On Sep 6, 2011, at 8:41, Eric Covener wrote:
> On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen wrote:
>>> e.g. MaxRanges none | 0 (none) | unlimited | n>=1
>> 0 means unlimited - this is consistent across all of our configuration
>> directives. Please let's not change that here. It's what folks ex
On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen wrote:
>> e.g. MaxRanges none | 0 (none) | unlimited | n>=1
> 0 means unlimited - this is consistent across all of our configuration
> directives. Please let's not change that here. It's what folks expect it to
> mean. Let's not surprise them.
How abou
0 means unlimited - this is consistent across all of our configuration
directives. Please let's not change that here. It's what folks expect it to
mean. Let's not surprise them.
On Sep 6, 2011, at 8:09, Eric Covener wrote:
> On Tue, Sep 6, 2011 at 7:34 AM, Jim Jagielski wrote:
>> From the co
> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Dienstag, 6. September 2011 14:09
> To: dev@httpd.apache.org
> Subject: Re: MaxRanges
>
> On Tue, Sep 6, 2011 at 7:34 AM, Jim Jagielski wrote:
> > From the code, MaxRanges 0 means unlimited...
> >
> > Is that
On Tue, Sep 6, 2011 at 7:34 AM, Jim Jagielski wrote:
> From the code, MaxRanges 0 means unlimited…
>
> Is that what we want? I can envision some use-cases where
> an admin may want to disable ranges totally and MaxRanges
> is really the place to do that.
>
> How about a setting <0 means unlimited?
On Sep 6, 2011, at 7:55 AM, Plüm, Rüdiger, VF-Group wrote:
>
>
>> -Original Message-
>> From: Jim Jagielski [mailto:j...@jagunet.com]
>> Sent: Dienstag, 6. September 2011 13:34
>> To: dev@httpd.apache.org
>> Subject: MaxRanges
>>
>> From the code, MaxRanges 0 means unlimited...
>>
>>
> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Dienstag, 6. September 2011 13:34
> To: dev@httpd.apache.org
> Subject: MaxRanges
>
> From the code, MaxRanges 0 means unlimited...
>
> Is that what we want? I can envision some use-cases where
> an admin may
From the code, MaxRanges 0 means unlimited…
Is that what we want? I can envision some use-cases where
an admin may want to disable ranges totally and MaxRanges
is really the place to do that.
How about a setting <0 means unlimited? (yes, this involves some
code and logic changes)...
Now that the 2.2 stuff looks good, I'll be adding limit control
on the overlaps/reversals to trunk…
On Sep 5, 2011, at 6:37 PM, Jeff Trawick wrote:
> On Mon, Sep 5, 2011 at 3:39 PM, Jim Jagielski wrote:
>> Looks good to me...
>
> now in STATUS
>
14 matches
Mail list logo
