You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Guenter Knauf <fu...@apache.org> on 2011/09/25 17:17:03 UTC
httpd 2.0.65 - when?
Hi all,
currently the 2.0.65 release seems a bit forgotten ...
2.0.x STATUS reads:
2.0.65 : In maintainance. Jim proposes T&R 9/12-15 and offers to RM.
http://httpd.apache.org/security/CVE-2011-3192.txt mentions:
...
Version 2.0.65 has not been released, but will include this fix, and is
anticipated in September.
...
Jeff has already released APR-0.9.20 at 15-Sep-2011:
http://www.apache.org/dist/apr/Announcement0.9.html
but we have even not yet commited the 2.0.x byterange fix to 2.0.x-HEAD ...
if we still want to release in September as stated in the security
advice then we should asap start with the release process, or?
Gün.
Re: httpd 2.0.65 - when?
Posted by Jim Jagielski <ji...@jaguNET.com>.
We have a suggested patch in STATUS that addresses the 0- range
issue… Once approved, I plan to T&R.
On Sep 26, 2011, at 11:35 AM, Jim Jagielski wrote:
> All looks good… testing passes w/ no regressions so I'll
> likely tag and roll tomorrow AM.
>
> On Sep 25, 2011, at 11:38 AM, Jim Jagielski wrote:
>
>> Been a little… preoccupied... Will push this week (and try to
>> finalize the patch to propose).
>>
>> On Sep 25, 2011, at 11:17 AM, Guenter Knauf wrote:
>>
>>> Hi all,
>>> currently the 2.0.65 release seems a bit forgotten ...
>>>
>>> 2.0.x STATUS reads:
>>> 2.0.65 : In maintainance. Jim proposes T&R 9/12-15 and offers to RM.
>>>
>>> http://httpd.apache.org/security/CVE-2011-3192.txt mentions:
>>> ...
>>> Version 2.0.65 has not been released, but will include this fix, and is
>>> anticipated in September.
>>> ...
>>>
>>> Jeff has already released APR-0.9.20 at 15-Sep-2011:
>>> http://www.apache.org/dist/apr/Announcement0.9.html
>>>
>>> but we have even not yet commited the 2.0.x byterange fix to 2.0.x-HEAD ...
>>>
>>> if we still want to release in September as stated in the security advice then we should asap start with the release process, or?
>>>
>>> Gün.
>>>
>>>
>>
>
RE: httpd 2.0.65 - when?
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Stefan Fritsch [mailto:sf@sfritsch.de]
> Sent: Montag, 26. September 2011 18:30
> To: dev@httpd.apache.org
> Subject: Re: httpd 2.0.65 - when?
>
> On Monday 26 September 2011, Plüm, Rüdiger, VF-Group wrote:
> > > Agreed, if people decide our handling of range "0-" is not
> > > desirable, this would seem to be a showstopper on all three
> > > branches. Personally, I find the current behavior acceptable by
> > > the spec and per the underlying errata Roy has suggested.
> > >
> > > Clients should not be able to shift trivial processing (which
> > > the client is perfectly capable of performing) to the server in
> > > ways that increase network traffic or server load. HTTP/1.1
> > > conversations must be designed to efficiently utilize network
> > > bandwidth, and these particular clients did not do that. I'm on
> > > the fence whether we should restore such abuse.
> >
> > I agree with you, but I am leaning towards to revert this
> > behaviour, because there are too much "stupid" clients out there.
> > So it looks like the "smarter" party has to give in :-). Sigh.
>
> +1
>
> Also, as documented in the Mozilla Bugzilla, there have also
> been dumb
> servers which send "Accept-Ranges: bytes" but don't support ranges.
> So it's somewhat understandable that clients try different methods to
> determine range support. They should have used a partial
> range request
> instead of requesting the whole file, though :-(
Like 0-0 or -1
Regards
Rüdiger
Re: httpd 2.0.65 - when?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 26 September 2011, Plüm, Rüdiger, VF-Group wrote:
> > Agreed, if people decide our handling of range "0-" is not
> > desirable, this would seem to be a showstopper on all three
> > branches. Personally, I find the current behavior acceptable by
> > the spec and per the underlying errata Roy has suggested.
> >
> > Clients should not be able to shift trivial processing (which
> > the client is perfectly capable of performing) to the server in
> > ways that increase network traffic or server load. HTTP/1.1
> > conversations must be designed to efficiently utilize network
> > bandwidth, and these particular clients did not do that. I'm on
> > the fence whether we should restore such abuse.
>
> I agree with you, but I am leaning towards to revert this
> behaviour, because there are too much "stupid" clients out there.
> So it looks like the "smarter" party has to give in :-). Sigh.
+1
Also, as documented in the Mozilla Bugzilla, there have also been dumb
servers which send "Accept-Ranges: bytes" but don't support ranges.
So it's somewhat understandable that clients try different methods to
determine range support. They should have used a partial range request
instead of requesting the whole file, though :-(
Re: httpd 2.0.65 - when?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 26, 2011, at 12:12 PM, William A. Rowe Jr. wrote:
>
> Agreed, if people decide our handling of range "0-" is not desirable, this
> would seem to be a showstopper on all three branches. Personally, I find
> the current behavior acceptable by the spec and per the underlying errata
> Roy has suggested.
Agreed.
Re: How to treat "Range: bytes=0-"
Posted by Rainer Jung <ra...@kippdata.de>.
On 26.09.2011 19:07, Jim Jagielski wrote:
>
> On Sep 26, 2011, at 12:58 PM, Stefan Fritsch wrote:
>
>>
>> But we are breaking quite a few popular clients here: VLC, everything
>> based on lavf, firefox (the ogg media support).
>>
>> And httpd violates a SHOULD with the current form of RFC 2616 14.35.1:
>>
>> If a syntactically valid byte-range-set includes at least one byte-
>> range-spec whose first-byte-pos is less than the current length of
>> the entity-body, or at least one suffix-byte-range-spec with a non-
>> zero suffix-length, then the byte-range-set is satisfiable.
>> Otherwise, the byte-range-set is unsatisfiable.
>>
>> This means "0-" is satisfiable.
>>
>> If the byte-range-set
>> is unsatisfiable, the server SHOULD return a response with a status
>> of 416 (Requested range not satisfiable). Otherwise, the server
>> SHOULD return a response with a status of 206 (Partial Content)
>> containing the satisfiable ranges of the entity-body.
>>
>> In this case, I am strongly in favor of fixing the RFC first and
>> changing httpd's behaviour only after that.
>>
>
> Certainly we can have a config option on whether to
> be strict or loose about it…
>
> ie:
>
> strict: 0- returns 200
> loose: 0- returns 206
>
> and we can have 2.0 and 2.2's default be loose and 2.4's
> be strict.
+1
Rainer
Re: How to treat "Range: bytes=0-"
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 26, 2011, at 2:57 PM, Stefan Fritsch wrote:
> On Monday 26 September 2011, Jim Jagielski wrote:
>> Check out
>>
>> http://svn.apache.org/viewvc?rev=1175980&view=rev
>>
>> Note that '0-1023,1024-' merges to 0- and and single
>> range and should also now return a 206 (due to the change from
>>> = to > in the sum_lengths check)…
>
> Looks good to me. For 2.0/2.2, I think we only need the >= to > change
> because we don't merge.
>
We might as well fast track it, and keep it special… The
suggested patches do that.
Re: How to treat "Range: bytes=0-"
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 26 September 2011, Jim Jagielski wrote:
> Check out
>
> http://svn.apache.org/viewvc?rev=1175980&view=rev
>
> Note that '0-1023,1024-' merges to 0- and and single
> range and should also now return a 206 (due to the change from
> >= to > in the sum_lengths check)…
Looks good to me. For 2.0/2.2, I think we only need the >= to > change
because we don't merge.
Re: How to treat "Range: bytes=0-"
Posted by Jim Jagielski <ji...@jaguNET.com>.
Check out
http://svn.apache.org/viewvc?rev=1175980&view=rev
Note that '0-1023,1024-' merges to 0- and and single
range and should also now return a 206 (due to the change from
>= to > in the sum_lengths check)…
On Sep 26, 2011, at 2:01 PM, William A. Rowe Jr. wrote:
> The RFC won't be updated that quickly. And I doubt this is the sort
> of thing to put in a directive. We've really become lax about making
> any sort of substantial protocol decisions on behalf of the user, turning
> too many into 'well, it could be this way, or maybe that, good luck'.
>
> Here's the underlying reason to revert...
>
> If we are arguing for bandwidth efficiency, and the client must probe
> the server due to too many erronious accept-ranges: bytes responses,
> then probing with bytes '0-1' or even '0-1023', followed by another req
> for '1024-' for the remainder of the response is more bandwidth intensive
> than giving them the original results for a '0-' query.
>
> And if '0-1023,1024-' is not merged into a 200, it at least devolves
> into a multipart response consuming more response bandwidth than if
> we had satisfied the original '0-' with a single-part range response.
>
> I'm giving this a bunch of thought, and unless someone can demonstrate
> a less bandwidth-intensive way of probing that ranges are truly supported,
> then my -0 is rapidly shifting to a +1 for this requested fix.
>
Re: How to treat "Range: bytes=0-"
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/26/2011 12:07 PM, Jim Jagielski wrote:
>
> On Sep 26, 2011, at 12:58 PM, Stefan Fritsch wrote:
>
>>
>> But we are breaking quite a few popular clients here: VLC, everything
>> based on lavf, firefox (the ogg media support).
>>
>> And httpd violates a SHOULD with the current form of RFC 2616 14.35.1:
>>
>> If a syntactically valid byte-range-set includes at least one byte-
>> range-spec whose first-byte-pos is less than the current length of
>> the entity-body, or at least one suffix-byte-range-spec with a non-
>> zero suffix-length, then the byte-range-set is satisfiable.
>> Otherwise, the byte-range-set is unsatisfiable.
>>
>> This means "0-" is satisfiable.
>>
>> If the byte-range-set
>> is unsatisfiable, the server SHOULD return a response with a status
>> of 416 (Requested range not satisfiable). Otherwise, the server
>> SHOULD return a response with a status of 206 (Partial Content)
>> containing the satisfiable ranges of the entity-body.
>>
>> In this case, I am strongly in favor of fixing the RFC first and
>> changing httpd's behaviour only after that.
>>
>
> Certainly we can have a config option on whether to
> be strict or loose about it…
>
> ie:
>
> strict: 0- returns 200
> loose: 0- returns 206
>
> and we can have 2.0 and 2.2's default be loose and 2.4's
> be strict.
The RFC won't be updated that quickly. And I doubt this is the sort
of thing to put in a directive. We've really become lax about making
any sort of substantial protocol decisions on behalf of the user, turning
too many into 'well, it could be this way, or maybe that, good luck'.
Here's the underlying reason to revert...
If we are arguing for bandwidth efficiency, and the client must probe
the server due to too many erronious accept-ranges: bytes responses,
then probing with bytes '0-1' or even '0-1023', followed by another req
for '1024-' for the remainder of the response is more bandwidth intensive
than giving them the original results for a '0-' query.
And if '0-1023,1024-' is not merged into a 200, it at least devolves
into a multipart response consuming more response bandwidth than if
we had satisfied the original '0-' with a single-part range response.
I'm giving this a bunch of thought, and unless someone can demonstrate
a less bandwidth-intensive way of probing that ranges are truly supported,
then my -0 is rapidly shifting to a +1 for this requested fix.
Re: How to treat "Range: bytes=0-"
Posted by Jim Jagielski <ji...@jaguNET.com>.
Looking this over, I started with the below section:
if (sum_lengths >= clength) {
ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r,
"Sum of ranges not smaller than file, ignoring.");
return 0;
}
which, at 1st blush looks like what we need to worry about… if
sum_lengths == clength, we can assume they sent 0-…
But then I noticed how we are counting sum_lengths, and saw that
we have an issue.
Assume they send:
0-999,1002-9999,1-9999
and clen is 10000. When this is merged, we get the following
pattern:
0-999,1-9999
and we see that the subsequent sum of lengths is > clength
and we decide to go 200 on 'em. Anyway, this means we can't
use sum_lengths == clength as a check… It
And since we only merge once, we can get the absolute smallest
list of ranges that cover what they sent…
Sooooo, I suggest we look for an actual '0-' in their input
as the trigger for the 200/206 decision.
If we DO see that, should be force a single range? That is, if
they send:
1-100, 200-300, 0-, 30-9999
Should we ignore all but the 0- and send a single range
and 206?
Re: How to treat "Range: bytes=0-"
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 26, 2011, at 12:58 PM, Stefan Fritsch wrote:
>
> But we are breaking quite a few popular clients here: VLC, everything
> based on lavf, firefox (the ogg media support).
>
> And httpd violates a SHOULD with the current form of RFC 2616 14.35.1:
>
> If a syntactically valid byte-range-set includes at least one byte-
> range-spec whose first-byte-pos is less than the current length of
> the entity-body, or at least one suffix-byte-range-spec with a non-
> zero suffix-length, then the byte-range-set is satisfiable.
> Otherwise, the byte-range-set is unsatisfiable.
>
> This means "0-" is satisfiable.
>
> If the byte-range-set
> is unsatisfiable, the server SHOULD return a response with a status
> of 416 (Requested range not satisfiable). Otherwise, the server
> SHOULD return a response with a status of 206 (Partial Content)
> containing the satisfiable ranges of the entity-body.
>
> In this case, I am strongly in favor of fixing the RFC first and
> changing httpd's behaviour only after that.
>
Certainly we can have a config option on whether to
be strict or loose about it…
ie:
strict: 0- returns 200
loose: 0- returns 206
and we can have 2.0 and 2.2's default be loose and 2.4's
be strict.
How to treat "Range: bytes=0-"
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 26 September 2011, Jim Jagielski wrote:
> On Sep 26, 2011, at 12:20 PM, Plüm, Rüdiger, VF-Group wrote:
> > I agree with you, but I am leaning towards to revert this
> > behaviour, because there are too much "stupid" clients out
> > there. So it looks like the "smarter" party has to give in :-).
> > Sigh.
>
> Not when the stupid clients are also, from what I can tell, wrong…
>
> Just because some clients may be/are abusing the spec doesn't mean
> we need to support it :)
But we are breaking quite a few popular clients here: VLC, everything
based on lavf, firefox (the ogg media support).
And httpd violates a SHOULD with the current form of RFC 2616 14.35.1:
If a syntactically valid byte-range-set includes at least one byte-
range-spec whose first-byte-pos is less than the current length of
the entity-body, or at least one suffix-byte-range-spec with a non-
zero suffix-length, then the byte-range-set is satisfiable.
Otherwise, the byte-range-set is unsatisfiable.
This means "0-" is satisfiable.
If the byte-range-set
is unsatisfiable, the server SHOULD return a response with a status
of 416 (Requested range not satisfiable). Otherwise, the server
SHOULD return a response with a status of 206 (Partial Content)
containing the satisfiable ranges of the entity-body.
In this case, I am strongly in favor of fixing the RFC first and
changing httpd's behaviour only after that.
Re: httpd 2.0.65 - when?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/26/2011 11:44 AM, Jim Jagielski wrote:
>
> On Sep 26, 2011, at 12:20 PM, Plüm, Rüdiger, VF-Group wrote:
>>
>> I agree with you, but I am leaning towards to revert this behaviour, because there
>> are too much "stupid" clients out there. So it looks like the "smarter" party
>> has to give in :-). Sigh.
>>
>
> Not when the stupid clients are also, from what I can tell, wrong…
>
> Just because some clients may be/are abusing the spec doesn't mean we need
> to support it :)
Hold up... for an arbitrary definition of the word 'wrong'... would you
frame your interpretation of what they did incorrectly? There is some
distance between ineffective and erroneous.
Re: httpd 2.0.65 - when?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 26, 2011, at 12:20 PM, Plüm, Rüdiger, VF-Group wrote:
>
> I agree with you, but I am leaning towards to revert this behaviour, because there
> are too much "stupid" clients out there. So it looks like the "smarter" party
> has to give in :-). Sigh.
>
Not when the stupid clients are also, from what I can tell, wrong…
Just because some clients may be/are abusing the spec doesn't mean we need
to support it :)
RE: httpd 2.0.65 - when?
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: William A. Rowe Jr.
> Sent: Montag, 26. September 2011 18:13
> To: dev@httpd.apache.org
> Subject: Re: httpd 2.0.65 - when?
>
> On 9/26/2011 10:46 AM, Rainer Jung wrote:
> > On 26.09.2011 17:35, Jim Jagielski wrote:
> >> All looks good... testing passes w/ no regressions so I'll
> >> likely tag and roll tomorrow AM.
> >
> > Is there consensus how to handle the range "0-" returns 200
> problem? It
> > looks like the discussion for 2.2 is still open, but I
> haven't checked
> > whether that influences the 2.0 patch.
>
> Agreed, if people decide our handling of range "0-" is not
> desirable, this
> would seem to be a showstopper on all three branches.
> Personally, I find
> the current behavior acceptable by the spec and per the
> underlying errata
> Roy has suggested.
>
> Clients should not be able to shift trivial processing (which
> the client
> is perfectly capable of performing) to the server in ways
> that increase
> network traffic or server load. HTTP/1.1 conversations must
> be designed
> to efficiently utilize network bandwidth, and these particular clients
> did not do that. I'm on the fence whether we should restore
> such abuse.
>
I agree with you, but I am leaning towards to revert this behaviour, because there
are too much "stupid" clients out there. So it looks like the "smarter" party
has to give in :-). Sigh.
Regards
Rüdiger
Re: httpd 2.0.65 - when?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/26/2011 10:46 AM, Rainer Jung wrote:
> On 26.09.2011 17:35, Jim Jagielski wrote:
>> All looks good… testing passes w/ no regressions so I'll
>> likely tag and roll tomorrow AM.
>
> Is there consensus how to handle the range "0-" returns 200 problem? It
> looks like the discussion for 2.2 is still open, but I haven't checked
> whether that influences the 2.0 patch.
Agreed, if people decide our handling of range "0-" is not desirable, this
would seem to be a showstopper on all three branches. Personally, I find
the current behavior acceptable by the spec and per the underlying errata
Roy has suggested.
Clients should not be able to shift trivial processing (which the client
is perfectly capable of performing) to the server in ways that increase
network traffic or server load. HTTP/1.1 conversations must be designed
to efficiently utilize network bandwidth, and these particular clients
did not do that. I'm on the fence whether we should restore such abuse.
RE: httpd 2.0.65 - when?
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
> Sent: Montag, 26. September 2011 17:47
> To: dev@httpd.apache.org
> Subject: Re: httpd 2.0.65 - when?
>
> On 26.09.2011 17:35, Jim Jagielski wrote:
> > All looks good... testing passes w/ no regressions so I'll
> > likely tag and roll tomorrow AM.
>
> Is there consensus how to handle the range "0-" returns 200
> problem? It
> looks like the discussion for 2.2 is still open, but I haven't checked
> whether that influences the 2.0 patch.
I think it does. So good point. So IMHO it makes sense to discuss this
first and patch afterwards.
Regards
Rüdiger
Re: httpd 2.0.65 - when?
Posted by Rainer Jung <ra...@kippdata.de>.
On 26.09.2011 17:35, Jim Jagielski wrote:
> All looks good… testing passes w/ no regressions so I'll
> likely tag and roll tomorrow AM.
Is there consensus how to handle the range "0-" returns 200 problem? It
looks like the discussion for 2.2 is still open, but I haven't checked
whether that influences the 2.0 patch.
Regards,
Rainer
Re: httpd 2.0.65 - when?
Posted by Jim Jagielski <ji...@jaguNET.com>.
All looks good… testing passes w/ no regressions so I'll
likely tag and roll tomorrow AM.
On Sep 25, 2011, at 11:38 AM, Jim Jagielski wrote:
> Been a little… preoccupied... Will push this week (and try to
> finalize the patch to propose).
>
> On Sep 25, 2011, at 11:17 AM, Guenter Knauf wrote:
>
>> Hi all,
>> currently the 2.0.65 release seems a bit forgotten ...
>>
>> 2.0.x STATUS reads:
>> 2.0.65 : In maintainance. Jim proposes T&R 9/12-15 and offers to RM.
>>
>> http://httpd.apache.org/security/CVE-2011-3192.txt mentions:
>> ...
>> Version 2.0.65 has not been released, but will include this fix, and is
>> anticipated in September.
>> ...
>>
>> Jeff has already released APR-0.9.20 at 15-Sep-2011:
>> http://www.apache.org/dist/apr/Announcement0.9.html
>>
>> but we have even not yet commited the 2.0.x byterange fix to 2.0.x-HEAD ...
>>
>> if we still want to release in September as stated in the security advice then we should asap start with the release process, or?
>>
>> Gün.
>>
>>
>
Re: httpd 2.0.65 - when?
Posted by Jim Jagielski <ji...@jaguNET.com>.
Been a little… preoccupied... Will push this week (and try to
finalize the patch to propose).
On Sep 25, 2011, at 11:17 AM, Guenter Knauf wrote:
> Hi all,
> currently the 2.0.65 release seems a bit forgotten ...
>
> 2.0.x STATUS reads:
> 2.0.65 : In maintainance. Jim proposes T&R 9/12-15 and offers to RM.
>
> http://httpd.apache.org/security/CVE-2011-3192.txt mentions:
> ...
> Version 2.0.65 has not been released, but will include this fix, and is
> anticipated in September.
> ...
>
> Jeff has already released APR-0.9.20 at 15-Sep-2011:
> http://www.apache.org/dist/apr/Announcement0.9.html
>
> but we have even not yet commited the 2.0.x byterange fix to 2.0.x-HEAD ...
>
> if we still want to release in September as stated in the security advice then we should asap start with the release process, or?
>
> Gün.
>
>