+++ 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: https://issues.apache.org/bugzilla/show_bug.cgi?id=51748 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: http://svn.apache.org/viewvc?view=revision&revision=1165607
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?
(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: https://bugzilla.redhat.com/show_bug.cgi?id=736592#c6 Behaviour for that case has been changed upstream several times: http://svn.apache.org/viewvc?view=revision&revision=1163833 http://svn.apache.org/viewvc?view=revision&revision=1165062 http://svn.apache.org/viewvc?view=revision&revision=1175980
I see, but is it also desirable that a security patch changes functionality in an otherwise frozen release downstream?
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. http://rhn.redhat.com/errata/RHSA-2011-1392.html