[PATCH] Range filter: always support ascending multipart ranges.

[Robert Burke]

Hello again :)

> If you think you want to add support nevertheless, you may want to
> elaborate more on why you need it. In my practice there are very
> few legitimate users of multipart ranges, and at least some of
> these actually benefit from disabling ranges support completely.

Sure. I might distribute software patches for a large software project
like so: my patcher downloads an index file. That file says that there
is one really big file at some URL containing various files used by
the software at various byte-ranges. The patcher makes some multipart
range requests for that URL, asking for only the ranges that
correspond to the files it needs to update. If the patcher instead
gets the whole thing, my user is sad because he or she has to wait to
download many times more data than expected.

This is a strange way to do things. Why would I want to do it? Well, I
want to let my users patch from a large number of old versions of my
software to the current version (e.g. from versions 7000-10999 to
version 11000) without downloading multiple versions of the same file
and without just downloading the whole thing. I also want to minimize
the number of round trips and connections, since RTT or connection
overhead could dominate if I am requesting a bunch of tiny files one
by one or in parallel.

I hope this example is useful. Ultimately we make changes like this
because our customers want them.

I attached a version of the patch that applies cleanly given the
recent upstream changes to range filter.

Thanks,
Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ascending_multi_ranges.patch
Type: application/octet-stream
Size: 16288 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20190618/f23ef2cb/attachment.obj>