Re: #311: Denial of Service and Ranges

I think that may be arbitrary overhead to try and comply with for the
implementations and this should be left to more of a
firewall/application-delivery layer.

I think this is too arbitrary and the implementation should focus on having
limits when its algorithms attempt to parse and serve a set of ranges.

Humbly,

Dale

2011/11/23 Mark Nottingham <mnot@mnot.net>

> Roy raised the following about p5:
>
> Servers that support Range requests as defined by 2616 are vulnerable to
> denial of service attacks due to the potential presence of many small or
> overlapping ranges. We can fix this by adding the following requirements:
>
> 1) Clients MUST NOT send Range requests containing multiple byterange
> specifiers that overlap. Servers MAY coalesce such overlapping ranges into
> a single range, regardless of the order those ranges are specified in the
> Range header field, or MAY respond with a 416 or 200 status instead.
>
> 2) Clients MUST NOT send Range requests containing multiple byterange
> specifiers that have a gap between ranges of less than 80 bytes, since the
> transmission overhead of multipart/byteranges parts is generally more than
> 80 bytes per range and is a far more significant burden on the server than
> simply transmitting the gap. Servers MAY coalesce multiple ranges with gaps
> smaller than the size of the corresponding multipart overhead, regardless
> of the order that those ranges are specified in the Range header field, or
> MAY respond with a 416 or 200 status instead.
>
> 3) Clients that send Range requests containing multiple byterange
> specifiers MUST list those ranges in ascending order within the Range
> header field value. Servers MAY reorder multiple ranges if they are not
> requested in ascending order, or respond with a 416 or 200 status instead.
>
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311>
>
> Any comments? If not, we'll incorporate into the next drafts for review.
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>