Re: #311: Denial of Service and Ranges

I'd be keen to see something that allowed a server to deliver a single 
range that encompassed all requested ranges, regardless of whether there 
were gaps or overlaps in the requested ranges.

then the server could avoid multipart response types.

Adrien


On 24/11/2011 5:52 p.m., William A. Rowe Jr. wrote:
> On 11/23/2011 10:24 PM, Mark Nottingham wrote:
>> 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.
>
> That should be SHOULD NOT, I suspect.  It's stupid, but not nearly as 
> stupid
> as asking for the same bytes 2x over.
>
> It's easier to say servers are always permitted to coalesce responses 
> in a
> manner that makes delivery more efficient.  I believe this needs to 
> include
> sequencing them in serial order as mentioned in...
>
>> 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.
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

Received on Thursday, 24 November 2011 05:00:59 UTC