I dont think that Squid2.7 could cache thing content unless it is
fully Http/1.1 supported but is there any work around to force caching
such a content because this URL is causing a big delay when the
startup of Youtube Video happens as Youtube Videos are being cached
then you wait about 7seconds to 9 seconds waiting till Youtube Video
starts to load.
YouTube is always changing its content & the way they allow their
partner video provider such a company to show a "LOGO" of their own.
When you log its content then you notice few output video url like
(*.youtube.com/generate_204) , (*.youtube.com/get_video) or
(*.youtube.com/videoplayback) and sometimes the ID can be seen at the
end of URL or sometimes can be seen in the middle of the URL and some
of the remaining few videos you can see at the start of URL after
"videoplayback" .. wondering why I cant see such information on
http://wiki.squid-cache.org/ConfigExamples/DynamicContent/YouTube ..
maybe it is not updated yet ?.
>Caching this could present clients with a lie,
> indicating that some server state has been changed when the server has not
> even been contacted.
I thought of caching this content
http://www.youtube-nocookie.com/gen_204?attributionpartner=vevo just
to reduce the big latency even if the video was cached. I found it
interesting to cache the whole videos at Youtube thats why I preffer
presenting clients with a lie avoiding the big latency.
Ghassan
On Thu, Nov 17, 2011 at 4:41 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On Thu, 17 Nov 2011 02:54:54 +0200, Ghassan Gharabli wrote:
>>
>> Hello,
>>
>> I was wondering what would we do with this URL
>> http://www.youtube-nocookie.com/gen_204?attributionpartner=vevo if we
>> want to cache it.
>>
>>
>> I'e been looking and found that its expire header has an invalid date
>> ! . I thought I can cache it since it has no-cache but as I can see
>> the object can be cached & cant be served without validation.
>>
>>
>> Isthere any other way that I can force it to cache ?
>
>
> RFC 2048 (HTTP/1.0) requires that invalid Expires: headers are treated as
> already expired regardless of their value. Under HTTP/1.1 this could be
> cached and served stale.
>
> However ... the status code is 204. Merely passing the URL to the web server
> changes some state there. Caching this could present clients with a lie,
> indicating that some server state has been changed when the server has not
> even been contacted. Also, the presence of no-cache and absence of max-stale
> means the server must be contacted on every re-use. Since there is no reply
> body content involved there is zero benefit from caching this. In fact a net
> loss in cache efficiency as one entry gets filled with an object which is
> guaranteed to be fully replaced on every usage.
>
>
> Amos
>
>
Received on Thu Nov 17 2011 - 12:26:30 MST
This archive was generated by hypermail 2.2.0 : Fri Nov 18 2011 - 12:00:03 MST