Bug 736593 - httpd: RHSA-2011:1245 regressions [rhel-5]
Summary: httpd: RHSA-2011:1245 regressions [rhel-5]
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: httpd
Version: 5.7
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Joe Orton
QA Contact: BaseOS QE Security Team
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-08 08:00 UTC by Tomas Hoger
Modified: 2018-11-14 10:29 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-20 16:56:41 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1392 normal SHIPPED_LIVE Moderate: httpd security and bug fix update 2011-10-20 16:56:30 UTC
Red Hat Knowledge Base (Legacy) 61709 None None None Never

Description Tomas Hoger 2011-09-08 08:00:26 UTC
+++ This bug was initially created as a clone of Bug #736592 +++

Description of problem:
RHSA-2011:1245 provided a fix for CVE-2011-3192, which significantly changed Ranges handling code and resulted in few regressions:

suffix-byte-range-spec ("-" suffix-length) were handled as equivalent to 0-suffix-length, resulting in the first suffix-length + 1 bytes being returned, rather than last suffix-length bytes.  Reported upstream in:

httpd did not return 416 error when all specified ranges were unsatisfiable. This can happen if range specification is syntactically incorrect, or if first-byte-pos is behind the end of the file.

The fix as applied to upstream 2.2.x SVN branch:

Comment 5 bugreports2005 2011-10-12 09:10:32 UTC
According to comment 32 of Bug #732928, the server also wrongly returns 200 OK when 206 Partial is expected.

I think we are being hit by this, and I don't see a mention of it above. Should there be one?

Comment 6 Tomas Hoger 2011-10-13 14:14:38 UTC
(In reply to comment #5)
> According to comment 32 of Bug #732928, the server also wrongly returns 200 OK
> when 206 Partial is expected.

Also noted in:

Behaviour for that case has been changed upstream several times:

Comment 8 bugreports2005 2011-10-19 11:39:50 UTC
I see, but is it also desirable that a security patch changes functionality in an otherwise frozen release downstream?

Comment 9 errata-xmlrpc 2011-10-20 16:56:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.