Re: A youtube and windows update cache thing.

On 05/28/2013 03:14 AM, Reiner Karlsberg wrote:

>> As far as I know squid serves 206 partial responses from cache only if
>> the full object exists in cache.

> I can not follow the flow of execution in squid2.7, but I am not shure,
> that you are correct.
> These excerpts from squi2.7 MIGHT indicate, that transmission of
> data for a range request to the client can start before the complete
> object is cached:
>
> squid.conf:
>
> # TAG: range_offset_limit (bytes)
> # Sets a upper limit on how far into the the file a Range request
> # may be to cause Squid to prefetch the whole file. If beyond this
> # limit Squid forwards the Range request as it is and the result
> # is NOT cached.
> #
> # This is to stop a far ahead range request (lets say start at 17MB)
> # from making Squid fetch the whole object up to that point
> before <=============================
> # sending anything to the client.
>
>
>
> client_side.c:
> clientCheckRangeForceMiss(StoreEntry * entry, HttpHdrRange * range)
> {
> /*
> * If the range_offset_limit is NOT in effect, there
> * is no reason to force a miss.
> */
> if (0 == httpHdrRangeOffsetLimit(range))
> return 0;
> /*
> * Here, we know it's possibly a hit. If we already have the
> * whole object cached, we won't force a miss.
> */
> if (STORE_OK == entry->store_status)
> return 0; /* we have the whole object */
> /*
> * Now we have a hit on a PENDING object. We need to see
> <===========================================
> * if the part we want is already cached. If so, we don't
> * force a miss.
> */
> assert(NULL != entry->mem_obj);
> if (httpHdrRangeFirstOffset(range) <= entry->mem_obj->inmem_hi)
> return 0;
> /*
> * Even though we have a PENDING copy of the object, we
> * don't want to wait to reach the first range offset,
> * so we force a miss for a new range request to the
> * origin.
> */
> return 1;
> }

I have not looked at the Squid2 code in a while, but your analysis seems
correct.

On 05/28/2013 07:27 AM, Amos Jeffries wrote:
> This looks like a collapsed_forwarding code check to me.

Collapsed forwarding deals with cases where there would normally be no
public store entry for the pending request. In this case, that public
entry exists. It could exist because collapsed forwarding was enabled,
of course, but that is not the only possibility, and the above code
itself is not related to collapsed forwarding AFAICT.

HTH,

Alex.
Received on Tue May 28 2013 - 14:15:44 MDT