Bug 51725 - Multiple Range: request accepted as "Range: n-m"
Summary: Multiple Range: request accepted as "Range: n-m"
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.5-HEAD
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: RFC
Depends on:
Blocks:
 
Reported: 2011-08-26 04:41 UTC by kabe
Modified: 2011-09-09 15:32 UTC (History)
0 users



Attachments
Multiple Range: request lines trace (1.78 KB, text/plain)
2011-08-26 04:41 UTC, kabe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kabe 2011-08-26 04:41:09 UTC
Created attachment 27436 [details]
Multiple Range: request lines trace

Multiple Range: request as

Range: bytes=0-1
Range: 2-3

seems syntactically invalid, so the second Range: should be ignored.
(RFC 2616,14.16 Content-Range)

Apache seems to (correctly) coalesce the request to

Range: bytes=0-1,2-3

which IS syntactically correct, and processed accordingly.

Open issue: how should we handle and/or coalesce multiple Range: lines?
(classical Set-Cookie: have had the similar problem, having "," as data)


Trace on httpd.apache.org (Apache/2.3.8) follows:

===========
Requesting as
> Range: bytes=0-1
> Range: bytes=2-3
yielding only the first Range: being accepted.

===========
% telnet httpd.apache.org 80
Trying 140.211.11.131...
Connected to httpd.apache.org.
Escape character is '^]'.
GET http://httpd.apache.org/lists.html HTTP/1.0
Host: httpd.apache.org
Connection: close
Range: bytes=0-1
Range: bytes=2-3

HTTP/1.1 206 Partial Content
Date: Fri, 26 Aug 2011 03:38:35 GMT
Server: Apache/2.3.8 (Unix) mod_ssl/2.3.8 OpenSSL/1.0.0c
Last-Modified: Mon, 21 Mar 2011 18:52:05 GMT
ETag: "9b39af-5b7a-49f029fb47f40"
Accept-Ranges: bytes
Content-Length: 109
Vary: Accept-Encoding
Connection: close
Content-Type: multipart/byteranges; boundary=4ab6047b55edfcaa2


--4ab6047b55edfcaa2
Content-type: text/html
Content-range: bytes 0-1/23418

<!
--4ab6047b55edfcaa2--
Connection closed by foreign host.


===========
Requesting as
> Range: bytes=0-1
> Range: 2-3
yielding both Range: being accepted.

===========
% telnet httpd.apache.org 80
Trying 140.211.11.131...
Connected to httpd.apache.org.
Escape character is '^]'.
GET http://httpd.apache.org/lists.html HTTP/1.0
Host: httpd.apache.org
Connection: close
Range: bytes=0-1
Range: 2-3

HTTP/1.1 206 Partial Content
Date: Fri, 26 Aug 2011 03:42:38 GMT
Server: Apache/2.3.8 (Unix) mod_ssl/2.3.8 OpenSSL/1.0.0c
Last-Modified: Mon, 21 Mar 2011 18:52:05 GMT
ETag: "9b39af-5b7a-49f029fb47f40"
Accept-Ranges: bytes
Content-Length: 193
Vary: Accept-Encoding
Connection: close
Content-Type: multipart/byteranges; boundary=4ab60563258c1ccb0


--4ab60563258c1ccb0
Content-type: text/html
Content-range: bytes 0-1/23418

<!
--4ab60563258c1ccb0
Content-type: text/html
Content-range: bytes 2-3/23418

DO
--4ab60563258c1ccb0--
Connection closed by foreign host.
Comment 1 Jeff Trawick 2011-09-04 15:52:27 UTC
See the last paragraph of RFC 2616, S4.2.
My understanding of that text is that it is the client's responsibility to use multiple occurrences of a request header field only if it is valid to combine them with a comma.
As far as httpd: It does combine multiple-occurring fields with a comma without regards to the particular field (Cookie*, Range, whatever).
Comment 2 kabe 2011-09-05 02:26:09 UTC
The RFC 2616, S4.2 says
>   Multiple message-header fields with the same field-name MAY be
>   present in a message if and only if the entire field-value for that
>   header field is defined as a comma-separated list [i.e., #(values)].

>   It MUST be possible to combine the multiple header fields into one
>   "field-name: field-value" pair, without changing the semantics of the
>   message, by appending each subsequent field-value to the first, each
>   separated by a comma.

Since Range: field-value is defined as
	"bytes=" 1#( byte-range-spec | suffix-byte-range-spec )

this isn't splittable into multiple lines.

There should have been some discussion about this unsplittableness
during HTTP/1.1 standard. Recall anyone?


I don't think it's feasible to reject "Range: 2-3" line in the 
current Apache either, which involves syntax parsing 
BEFORE the header aggregation.

If nobody comes up with any serious issues (security?), this PR
could be closed(wontfix) and left for information purpose.
Comment 3 William A. Rowe Jr. 2011-09-09 15:32:52 UTC
You are correct, it can't be split between bytes=n-n and n-n lines per spec.

I'm looking right now at clarifications to the spec on this subject.  Unlike
our recent fix, detecting commas within Content-Length headers, we can't simply
look for a comma to determine if the ranges were merged.

A more comprehensive fix is needed in the long term which I am designing for
2.3 initially; in the short term our advisory will be updated per your feedback.
Thanks for the report.