httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: DoS with mod_deflate & range requests
Date Wed, 24 Aug 2011 21:19:20 GMT
On 8/24/2011 4:06 PM, Jim Jagielski wrote:
> I'm cool w/ that… treat non-ascending ranges as potential hinky
> and count those and only allow a certain number of them…
> Still not sure if we should count overlaps as bad or not…
> that RFC example troubles me:
> 14.35.1 Byte Ranges
>       - Several legal but not canonical specifications of the second 500
>         bytes (byte offsets 500-999, inclusive):
>          bytes=500-600,601-999
>          bytes=500-700,601-999
> The 2nd seems to imply that one *MUST* merge adjacent overlaps to get the
> correct response (500 bytes not 201+399=600bytes)
> With all that in mind, I am still of the opinion that any
> adjacent overlaps should be merged…
> So how about we parse Range and merge all adjacent overlaps
> (or merges (200-249,250-999 would merge into 200-999);
> We then count how many non-ascends are in that revised set of
> ranges and 200 out if it exceeds some config limit. We can also
> provide some overall limit on the number of ranges, or at least
> the ability to add one (a default of 0 means unlimited)…
> Sound OK?

Yup, sounds good.  The only question is non-adjacent overlaps.
Given Roy's pedantic example, I believe we should also start to
dismiss any gap of less than X (80 bytes?) and provide those
bytes as well in the merged range.

Yes, clients may break.  They were morons anyways for asking us
to skip a few bytes for them and increase network traffic.  Once
the author accommodates the fact that they aren't in control, the
response is semantically accurate.

For that matter, perhaps User-Agent could be used to determine if
we have a backwards-broken client for which we fall into the very
well documented 200 response.

View raw message