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
ascending_multi_ranges.patch
Description: Binary data
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
