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

 On Wed, 4 Jan 2012 19:18:59 -0500 (EST), Yves Lafon wrote:
> On Thu, 5 Jan 2012, Amos Jeffries wrote:
>
>> On Wed, 4 Jan 2012 09:00:38 -0500 (EST), Yves Lafon wrote:
>>> 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.
>>>>>
>>
>> Is the phrasing "have liability" defined somewhere? I may have 
>> missed it, but it still took me a few minutes to realise what this 
>> sentence meant despite being part of the discussions earlier around 
>> Range.
>
> Hum, I will rewrite that, but you got the spirit of it.
>

 Yes. Cheers. :)

>>> [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.
>>>>>>
>>
>> This last part seems to contradict my understanding of the last 
>> discussion consensus. That ranges could be combined to reduce DoS 
>> footprint.
>>
>> Did I get that completely out of place? or is this use of SHOULD a 
>> downgrade intended to permit it?
>
> I don't see a contradiction there, it just says that the ranges 
> should be
> sent in order, however when ranges are combined, ordering can become
> invalid (if the combined ranges were not directly following each

 invalid? I don't see that in the new texts. single-part "multipart" is 
 MAY, which should at most solve any validity issue on merging.

> other), so yes, it's the use of a SHOULD isntead of a MUST that 
> allows
> that, while giving general guidelines for the general "normal" case.
>

 Thanks. That answers the initial Q.

 AYJ

Received on Thursday, 5 January 2012 01:27:44 UTC