You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2011/09/06 13:34:01 UTC
MaxRanges
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)...
Re: MaxRanges
Posted by Eric Covener <co...@gmail.com>.
On Wed, Sep 7, 2011 at 10:41 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> +1… I don't think we should worry about overlaps and reversals
> in 2.2, just in trunk. So none/unlimited/#>0 for MaxRanges
> sounds good in both trunk and 2.2
Tried to address points ITT in trunk, and will look at 2.2.
Re: MaxRanges
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1… I don't think we should worry about overlaps and reversals
in 2.2, just in trunk. So none/unlimited/#>0 for MaxRanges
sounds good in both trunk and 2.2
On Sep 6, 2011, at 12:23 PM, Eric Covener wrote:
> On Tue, Sep 6, 2011 at 9:32 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>> On Sep 6, 2011, at 8:41 AM, Eric Covener wrote:
>>
>>> On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen <rb...@rcbowen.com> 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 about rejecting 0 if it's too loaded/ambiguous? Accept
>>> "unlimited", "none" and n>0 ?
>>>
>>
>> Sounds good… that allows for unlimited and none to be added
>> to trunk w/o changing anything in 2.2
>
> Just to make sure we're on the same page -- MaxRanges was not released
> yet in 2.2, so we can also update this in 2.2 to avoid confusion over
> "0" and the inability to set unlimited.
>
> Thoughts?
>
> --
> Eric Covener
> covener@gmail.com
>
Re: MaxRanges
Posted by Eric Covener <co...@gmail.com>.
On Tue, Sep 6, 2011 at 9:32 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Sep 6, 2011, at 8:41 AM, Eric Covener wrote:
>
>> On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen <rb...@rcbowen.com> 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 about rejecting 0 if it's too loaded/ambiguous? Accept
>> "unlimited", "none" and n>0 ?
>>
>
> Sounds good… that allows for unlimited and none to be added
> to trunk w/o changing anything in 2.2
Just to make sure we're on the same page -- MaxRanges was not released
yet in 2.2, so we can also update this in 2.2 to avoid confusion over
"0" and the inability to set unlimited.
Thoughts?
--
Eric Covener
covener@gmail.com
Re: MaxRanges
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 6, 2011, at 8:41 AM, Eric Covener wrote:
> On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen <rb...@rcbowen.com> 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 about rejecting 0 if it's too loaded/ambiguous? Accept
> "unlimited", "none" and n>0 ?
>
Sounds good… that allows for unlimited and none to be added
to trunk w/o changing anything in 2.2
Re: MaxRanges
Posted by Rich Bowen <rb...@rcbowen.com>.
On Sep 6, 2011, at 8:41, Eric Covener <co...@gmail.com> wrote:
> On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen <rb...@rcbowen.com> 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 about rejecting 0 if it's too loaded/ambiguous? Accept
> "unlimited", "none" and n>0 ?
+1
Re: MaxRanges
Posted by Eric Covener <co...@gmail.com>.
On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen <rb...@rcbowen.com> 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 about rejecting 0 if it's too loaded/ambiguous? Accept
"unlimited", "none" and n>0 ?
Re: MaxRanges
Posted by Rich Bowen <rb...@rcbowen.com>.
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 <co...@gmail.com> wrote:
> On Tue, Sep 6, 2011 at 7:34 AM, Jim Jagielski <ji...@jagunet.com> 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? (yes, this involves some
>> code and logic changes)...
>
> No magic reasons for current state here, I'd suggest teaching it to
> take strings as well as numbers so users don't need to know 0/-1
> significance
>
> e.g. MaxRanges none | 0 (none) | unlimited | n>=1
RE: MaxRanges
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Eric Covener [mailto:covener@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 <ji...@jagunet.com> 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? (yes, this involves some
> > code and logic changes)...
>
> No magic reasons for current state here, I'd suggest teaching it to
> take strings as well as numbers so users don't need to know 0/-1
> significance
>
> e.g. MaxRanges none | 0 (none) | unlimited | n>=1
>
+1
Regards
Rüdiger
Re: MaxRanges
Posted by Eric Covener <co...@gmail.com>.
On Tue, Sep 6, 2011 at 7:34 AM, Jim Jagielski <ji...@jagunet.com> 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? (yes, this involves some
> code and logic changes)...
No magic reasons for current state here, I'd suggest teaching it to
take strings as well as numbers so users don't need to know 0/-1
significance
e.g. MaxRanges none | 0 (none) | unlimited | n>=1
Re: MaxRanges
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 6, 2011, at 7:55 AM, Plüm, Rüdiger, VF-Group wrote:
>
>
>> -----Original Message-----
>> From: Jim Jagielski [mailto:jim@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 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)...
>
> In general yes. But this would also require that we do not sent Accept-Ranges any longer
> if MaxRanges is set to 0.
>
Yes… the plan would be to abide by 'May' in "14.5 Accept-Ranges"
and have httpd indicate none.
RE: MaxRanges
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Jim Jagielski [mailto:jim@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 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)...
In general yes. But this would also require that we do not sent Accept-Ranges any longer
if MaxRanges is set to 0.
Regards
Rüdiger