Summary: | Multiple Range: request accepted as "Range: n-m" | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | kabe <kabe> |
Component: | Core | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | NEW --- | ||
Severity: | normal | Keywords: | RFC |
Priority: | P2 | ||
Version: | 2.5-HEAD | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Attachments: | Multiple Range: request lines trace |
Description
kabe
2011-08-26 04:41:09 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). 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. 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. |