On 8/06/2013 1:43 a.m., csn233 wrote:
On Thu, Jun 6, 2013 at 11:24 PM, Eliezer Croitoru <eliezer@xxxxxxxxxxxx> wrote:
This is the best example to demonstrate how CDN urls are being and can be
used.
Right the next couple urls will result in the same storeID
http://freefr.dl.sourceforge.net/project/vlc/2.0.5/win32/vlc-2.0.5-win32.exe
http://freefr3.dl.sourceforge.net/project/vlc/2.0.5/win32/vlc-2.0.5-win32.exe
http://freefr2.dl.sourceforge.net/project/vlc/2.0.5/win32/vlc-2.0.5-win32.exe
http://freefr1.dl.sourceforge.net/project/vlc/2.0.5/win32/vlc-2.0.5-win32.exe
OK
store-id=http://dl.sourceforge.net.squid.internal/project/vlc/2.0.5/win32/vlc-2.0.5-win32.exe
There is not such thing as un-cachable from the proxy point of view but
rather what the proxy prefers to not cache.
Youtube example is a really good and complex one.
it was explained long before I wrote my helper and code.
The reason you might not understand it is that you need to learn a bit more
to make sure you understand what StoreID and what StoreUrlRewrite does.
I am here for that..
That is indeed a great example. 4 different URLs pointing to the same
StoreID, meaning the same cached copy can be served.
However, in the example I was pointing to, it shows a 1 to 1 rewrite.
It does not convey the same message that this 4-to-1 rewrite would,
for someone new to the concept. Do you understand that point?
Technically, StoreID may be implemented differently from StoreURL, but
from a conceptual user point of view they achieve exactly the same
thing. From a user point of view, they don't need to know the
difference, apart from the additional concurrency parameter and one
really crucial point (to me anyway) that the refresh_pattern is
applied after the rewrite for one, and before for the other. That got
me scratching my head a bit... :)
Aha. Would you mind reading through the draft 3.4 release notes on this
feature and checking that those points are highlighted enough or in the
right way?
http://master.squid-cache.org/Versions/v3/3.HEAD/RELEASENOTES.html#ss2.3
Amos