You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by fu...@apache.org on 2011/09/03 15:18:09 UTC
svn commit: r1164861 - /httpd/httpd/trunk/docs/conf/httpd.conf.in
Author: fuankg
Date: Sat Sep 3 13:18:09 2011
New Revision: 1164861
URL: http://svn.apache.org/viewvc?rev=1164861&view=rev
Log:
Added MaxRanges to httpd.conf.
Modified:
httpd/httpd/trunk/docs/conf/httpd.conf.in
Modified: httpd/httpd/trunk/docs/conf/httpd.conf.in
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/httpd.conf.in?rev=1164861&r1=1164860&r2=1164861&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/conf/httpd.conf.in (original)
+++ httpd/httpd/trunk/docs/conf/httpd.conf.in Sat Sep 3 13:18:09 2011
@@ -333,6 +333,12 @@ LogLevel warn
#
#
+# MaxRanges: Maximum number of Ranges in a request before
+# returning the entire resource, or 0 for unlimited
+# Default setting is to accept 200 Ranges
+#MaxRanges 0
+
+#
# EnableMMAP and EnableSendfile: On systems that support it,
# memory-mapping or the sendfile syscall may be used to deliver
# files. This usually improves server performance, but must
Re: svn commit: r1164861 - /httpd/httpd/trunk/docs/conf/httpd.conf.in
Posted by Guenter Knauf <fu...@apache.org>.
Bill,
Am 12.09.2011 04:33, schrieb William A. Rowe Jr.:
> On 9/3/2011 8:18 AM, fuankg@apache.org wrote:
>> Author: fuankg
>> Date: Sat Sep 3 13:18:09 2011
>> New Revision: 1164861
>>
>> URL: http://svn.apache.org/viewvc?rev=1164861&view=rev
>> Log:
>> Added MaxRanges to httpd.conf.
>>
>> Modified:
>> httpd/httpd/trunk/docs/conf/httpd.conf.in
>>
>> Modified: httpd/httpd/trunk/docs/conf/httpd.conf.in
>> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/httpd.conf.in?rev=1164861&r1=1164860&r2=1164861&view=diff
>> ==============================================================================
>> --- httpd/httpd/trunk/docs/conf/httpd.conf.in (original)
>> +++ httpd/httpd/trunk/docs/conf/httpd.conf.in Sat Sep 3 13:18:09 2011
>> @@ -333,6 +333,12 @@ LogLevel warn
>> #
>>
>> #
>> +# MaxRanges: Maximum number of Ranges in a request before
>> +# returning the entire resource, or 0 for unlimited
>> +# Default setting is to accept 200 Ranges
>> +#MaxRanges 0
>> +
>> +#
>> # EnableMMAP and EnableSendfile: On systems that support it,
>> # memory-mapping or the sendfile syscall may be used to deliver
>> # files. This usually improves server performance, but must
>
> Ok, the question is, why?
because I feel that we here did an important change in default
behaviour, and uncommenting the line ( = set to 0) did almost restore
old behaviour before we introduced the range fixes. Agreed that its now
wrong since the directive arguments changed *after* this commit, and I
as well as all others involved forgot to sync.
> Note that 2.2 is nominally borked due to the backport of this particular
> text in combination with r1166612 (but would emit an error if the 0 option
> were specified, so it's absolutely not a release showstopper).
>
> But I'm -1 to this change overall on trunk and branches. We long ago agreed
nice, but you should have vetoed this when it was only in trunk and not
backported to 2.2.x.
> that such flags didn't belong in the configuration, in fact none of the other
> 'security limit' directives along the lines of LimitRequestLines et al are
> in httpd.conf anymore. Just because we introduce a directive isn't a license
> to pollute our default config, and absolutely not httpd.conf [note that there
> are a host of conf/extra/ files loaded with example overrides].
Thanks for explaining - I wasnt aware of this agreement. BTW. what
warrants the lines about EnableMMAP and EnableSendfile in httpd.conf then?
> I'm happy to be dissuaded, but this shouldn't be necessary for most admins,
> unless something were discovered down the road that makes it appropriate
> for admins to enable (and then, we would broadcast an announcement along
> those lines). I'm especially worried as it seems we are in for a boatload
> of new config directives for one aspect of the http protocol, and I'm not
> looking forward to so many extraneous .conf lines.
>
> I propose to revert this on trunk before we tag beta 2.3.15 unless there
> is some compelling reason for it to remain.
I've just fixed the MaxRanges config block in trunk; go and remove it if
it is wrong.
Gün.
Re: svn commit: r1164861 - /httpd/httpd/trunk/docs/conf/httpd.conf.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/3/2011 8:18 AM, fuankg@apache.org wrote:
> Author: fuankg
> Date: Sat Sep 3 13:18:09 2011
> New Revision: 1164861
>
> URL: http://svn.apache.org/viewvc?rev=1164861&view=rev
> Log:
> Added MaxRanges to httpd.conf.
>
> Modified:
> httpd/httpd/trunk/docs/conf/httpd.conf.in
>
> Modified: httpd/httpd/trunk/docs/conf/httpd.conf.in
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/httpd.conf.in?rev=1164861&r1=1164860&r2=1164861&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/docs/conf/httpd.conf.in (original)
> +++ httpd/httpd/trunk/docs/conf/httpd.conf.in Sat Sep 3 13:18:09 2011
> @@ -333,6 +333,12 @@ LogLevel warn
> #
>
> #
> +# MaxRanges: Maximum number of Ranges in a request before
> +# returning the entire resource, or 0 for unlimited
> +# Default setting is to accept 200 Ranges
> +#MaxRanges 0
> +
> +#
> # EnableMMAP and EnableSendfile: On systems that support it,
> # memory-mapping or the sendfile syscall may be used to deliver
> # files. This usually improves server performance, but must
Ok, the question is, why?
Note that 2.2 is nominally borked due to the backport of this particular
text in combination with r1166612 (but would emit an error if the 0 option
were specified, so it's absolutely not a release showstopper).
But I'm -1 to this change overall on trunk and branches. We long ago agreed
that such flags didn't belong in the configuration, in fact none of the other
'security limit' directives along the lines of LimitRequestLines et al are
in httpd.conf anymore. Just because we introduce a directive isn't a license
to pollute our default config, and absolutely not httpd.conf [note that there
are a host of conf/extra/ files loaded with example overrides].
I'm happy to be dissuaded, but this shouldn't be necessary for most admins,
unless something were discovered down the road that makes it appropriate
for admins to enable (and then, we would broadcast an announcement along
those lines). I'm especially worried as it seems we are in for a boatload
of new config directives for one aspect of the http protocol, and I'm not
looking forward to so many extraneous .conf lines.
I propose to revert this on trunk before we tag beta 2.3.15 unless there
is some compelling reason for it to remain.