Re: Collapse forwarding range_offset_limit and 206 requests?

Thanks.

Now I understood better the range_offset_limit.
So it means that a range request that will try to download a file from
size 1k to 20k will cause a 900MB file to be fetched into cache.
and a request between the range_offset_limit and up will not trigger a
full object fetch.
Now just a note that "http://download.microsoft.com/download/" urls and
maybe some others can contain objects which are far more then just 100MB
but rather can be 300+ 500+ etc which are service packs and these are
less frequently requested automatically by clients but it is possible
for them to be downloaded pretty frequently.

Response Headers: microsoft updates server do use ETAGs and do provide
legit Last-Modified responses which gives squid "reload-into-ims" usage
it's power.

If anyone needs windows updates for a network of more then let say 50
PCs I would assume their update policy is stricter and will be
maintained by a Admin(s?) and\or WSUS.

For an ISP environment I assume there is no WSUS or admin that will
update all of their clients PCs so this is where the mentioned tweaks
are recommended for.

Just remembered that in squid versions older then 3.2 which the
range_offset_limit was not used with ACL list (such as 2.7) the
range_offset_limit would apply to all incoming requests to the server
and might cause some very series bandwidth abusing if used with
"quick_abort_min -1" while a range request will cause only partial
abusing of this bandwidth.

So what will happen with a "quick_abort_min -1", "quick_abort_min 95%"
or any other values?
Let say a client starts a download of a 900MB file and quick_abort_min
-1 is used, will what I think(the whole 900MB file will be downloaded no
matter if the client aborted the request?) will happen?

If the above case is indeed true I would suggest to use a dedicated
WindowsUpdates cache_peer for these specific requests\domains and to
disable the option of cache abusing by rouge clients which needs to be
notified about their abusive usage of the service.

Thanks,
Eliezer

On 11/10/2013 10:45 PM, Amos Jeffries wrote:
> Ah. Thank you. I've updated the page a bit for those settings.
>
> I know the windowsupdate ACL list is not outdated after some XP archive
> changes and thr addition of Windows8 downloads. Additions there are
> welcome.
>
> Amos
Received on Sun Nov 10 2013 - 21:26:38 MST