#311 Add limitations to Range to reduce its use as a denial-of-service tool

Here is a proposal to clarify a few things to help mitigating the 
overlapping range DoS issue:

1/ split section 4 in Combining Range in Caches (the actual content)
    and add a specific section about combining ranges in responses.
    (with a link to security considerations, and link back from security
    section to this newly created section.

2/ Responses to single and multiple range requests / Combining Ranges in a 
response.

Add:
<<
    Servers have liability to combine requested ranges when those ranges
    are ovelapping.
>>
[Move this part of 5.2 here]
<<
    When an HTTP message includes the content of a single range (for
    example, a response to a request for a single range, or to a request
    for a set of ranges that overlap without any holes), this content is
    transmitted with a Content-Range header field, and a Content-Length
    header field showing the number of bytes actually transferred.  For
    example,

      HTTP/1.1 206 Partial Content
      Date: Wed, 15 Nov 1995 06:25:24 GMT
      Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
      Content-Range: bytes 21010-47021/47022
      Content-Length: 26012
      Content-Type: image/gif

    When an HTTP message includes the content of multiple ranges (for
    example, a response to a request for multiple non-overlapping
    ranges), these are transmitted as a multipart message.  The multipart
    media type used for this purpose is "multipart/byteranges" as defined
    in Appendix A.

    A response to a request for a single range MUST NOT be sent using the
    multipart/byteranges media type.  A response to a request for
    multiple ranges, whose result is a single range, MAY be sent as a
    multipart/byteranges media type with one part.  A client that cannot
    decode a multipart/byteranges message MUST NOT ask for multiple
    ranges in a single request.

    When a client requests multiple ranges in one request, the server
    SHOULD return them in the order that they appeared in the request.
>>>

Slash the following paragraph

<<
    If the server receives a request (other than one including an If-
    Range header field) with an unsatisfiable Range header field (that
    is, all of whose byte-range-spec values have a first-byte-pos value
    greater than the current length of the selected resource), it SHOULD
    return a response code of 416 (Requested range not satisfiable)
    (Section 3.2).
>>
As it is redundant, and add an example to 3.2 and the following note:
<<
       Note: Clients cannot depend on servers to send a 416 (Requested
       range not satisfiable) response instead of a 200 (OK) response for
       an unsatisfiable Range header field, since not all servers
       implement this header field.
>>

<<
HTTP/1.1 416 Requested Range Not Satisfiable
Content-Range: */42
...
>>

Always allow the server to ignore range requests

<<
    If the server ignores a byte-range-spec because it is syntactically
    invalid, the server SHOULD treat the request as if the invalid Range
    header field did not exist.  (Normally, this means return a 200
    response containing the full representation).
>>
becomes
<<
    If the server ignores a byte-range-spec (for example if it is
    syntactically, or if it may be seen as a denial-of-service attack),
    the server SHOULD treat the request as if the invalid Range header
    field did not exist.  (Normally, this means return a 200
    response containing the full representation).
>>

As in all cases where the server detect some potential abuses/DoS attempts 
etc... It can close the connection, response with a 403 or do whatever is 
needed.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 4 January 2012 14:02:40 UTC