Bug 51878 - 2.2.21 is not compliant for byterange 0- returning 200 instead of 206
2.2.21 is not compliant for byterange 0- returning 200 instead of 206
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: All
2.2.21
PC Linux
: P2 normal (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: FixedInTrunk
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-09-22 23:13 UTC by galt
Modified: 2014-02-17 13:44 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description galt 2011-09-22 23:13:08 UTC
2.2.21 is not compliant for byterange 0- returning 200 instead of 206.

This breaks our software.
We see the 200 response as a failure to understand the byterange request.

http://httpd.apache.org/security/CVE-2011-3192.txt
The fixes for CVE-2011-3192 in 2.2.20 and 2.2.21 are causing
servers to return 200 instead of 206 for this case.
(see the CAVEATS section of CVE-2011-3192).

RFC
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Section 14.35.1 Byte Ranges says that, if the requested range is satisfiable, 
and 0- certainly is, then "the server SHOULD return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the entity-body. "

People everywhere should not have to dink around with their clients software.
You should follow the standard.  It should be easy for you to fix this.

-Thank you!
Galt Barber
UCSC Genome Browser
Comment 1 William A. Rowe Jr. 2011-09-22 23:28:09 UTC
As a request for 0- is satisfiable as either a 200, a 206 single item response, or a 206 multiple ranges response, the server appears free to make the most efficient bandwidth and processing cycles election of responses.

All clients must degrade gracefully to 200 replies, per spec, and changing this newly introduced behavior is very unlikely.
Comment 2 galt 2011-09-22 23:36:50 UTC
Here's what someone else wrote on the issue:

https://developer.mozilla.org/en/Configuring_servers_for_Ogg_media

<quote>

Handle HTTP 1.1 byte range requests correctly

In order to support seeking and playing back regions of the media that aren't yet downloaded, Gecko uses HTTP 1.1 byte-range requests to retrieve the media from the seek target position. In addition, if you don't serve X-Content-Duration headers, Gecko uses byte-range requests to seek to the end of the media (assuming you serve the Content-Length header) in order to determine the duration of the media.

Your server should accept the "Accept-Ranges: bytes" HTTP header if it can accept byte-range requests. It must return "206: Partial content" to all byte range requests; otherwise, Gecko can't be sure you actually support byte range requests.

Your server must also return "206: Partial Content" for the request "Range: bytes=0-" as well.

</quote>
Comment 3 Stefan Fritsch 2011-09-23 21:44:58 UTC
In addition to gecko (i.e. firefox) and libavformat (as reported on the dev list), vlc is also broken by this change. This means that it breaks quite a few popular video players. Therefore I am for reverting this change. We have workarounds for other clients in the code, too.

Maybe Roy can get it clarified in HTTP/1.1bis that this is expected behaviour, and then we can change it back again in httpd 3.0.
Comment 4 Stefan Fritsch 2011-09-28 21:50:19 UTC
trunk: r1175980, r1175992
2.2.x: r1177080 will be in 2.2.22
Comment 5 galt 2011-09-28 23:32:35 UTC
Thanks for the quick fix!
Any idea when 2.2.22 will be released?
We have users that will be eager to get it.
Comment 6 William A. Rowe Jr. 2011-09-28 23:46:17 UTC
There are no plans at present.

2.2.22 isn't likely to be released until we have feedback from the community
who report such issues... sf gave you the link to the patch (click on r1177080 
above), if you can apply to 2.2.21 and report back if it resolves all of your
observed issues, or if you continue to see misbehavior, this would be very
helpful towards moving to the 2.2.22 release.

For completeness, here's my own counter-argument documenting why reverting this behavior is appropriate from a bandwidth consumption perspective;

http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E80BDF7.8040601@rowe-clan.net%3E
Comment 7 galt 2011-10-05 18:42:15 UTC
We have tested the patch here at UCSC against 2.2.21 and it worked fine.
Comment 8 galt 2011-10-05 20:08:29 UTC
Just to make the point, if the client software asks for x,y,z,
but apache returns w (even if technically w is a superset of x,y,z),
then the client will know what to do with w.

The way we use apache here is for random access to huge files,
often 180GB or larger. We sure as heck don't want the whole file back.
We usually read the header block (request 1), which tells 
where to find the index (request 2), which tells us were 
to jump to in the data (request 3).  Of course we cache things.
We do not ask for multiple blocks at once.

With some formats, we are able to determine in advance how
much we are reading, but with others we do not know ahead of 
time when we will stop reading, so that the range end is unknown.

Since 200 is what servers that do not support byteranges return,
we reject those servers as soon as we see the header.
It must be 206 to continue.  The fact that there is just one 
case where the part is equal to the whole, does not mean
that we want a 200 instead of a 206.
Comment 9 galt 2011-10-05 20:13:13 UTC
(In reply to comment #8)
oops, meant to say:

> then the client will NOT know what to do with w.
Comment 10 matty 2012-03-21 11:39:21 UTC
When "killapache.pl" script is executed against Opensource Apache 2.2.22 Windows binary, it shows "host seems vuln" message. This behaviour was not observed in Apache 2.2.21 version. Whether this means CVE-2011-3192 vulnerability is re-introduced in Opensource Apache 2.2.22 version while fixing the below byterange regression?
 
*) Fix a regression introduced by the CVE-2011-3192 byterange fix in 2.2.20:
A range of '0-' will now return 206 instead of 200. PR 51878.
[Jim Jagielski]
Comment 11 Eric Covener 2012-03-21 12:04:32 UTC
(In reply to comment #10)
> When "killapache.pl" script is executed against Opensource Apache 2.2.22
> Windows binary, it shows "host seems vuln" message. This behaviour was not
> observed in Apache 2.2.21 version. Whether this means CVE-2011-3192
> vulnerability is re-introduced in Opensource Apache 2.2.22 version while fixing
> the below byterange regression?
> 
> *) Fix a regression introduced by the CVE-2011-3192 byterange fix in 2.2.20:
> A range of '0-' will now return 206 instead of 200. PR 51878.
> [Jim Jagielski]

No, it means killapache.pl has crude detection for vulnerable hosts.  It flags any system that responds to range headers.