well i implemented the deicated squid 2.7 server and ti works fine.
it took me awhile to understand how the squid peering system works.
what i did was to deny all icp-htcp features and also denied direct
access to youtube on the main cache server
and i added the cache peer for the youtube domain and it works.
the settings for that is:
cache_peer youtubeproxy.lan parent 3128 3130 no-digest no-delay
cache_peer_domain youtubeproxy.lan .youtube.com
cache_peer_access youtubeproxy.lan allow youtube
cache_peer_access youtubeproxy.lan deny localnet
icp_access allow localnet
never_direct allow youtube
well i dont use the icp but in any case i will want to do something with
it for the testing i added the icp/htcp.
and in the mean while i got some null:// error screens from the 3.1.11
squid.
i managed to repeat the problem\bug while using
refresh_pattern -i . 0 20% 4320 override-expire
if you want me to do something to help find the bug or any information
just say it.
On 16/02/2011 23:56, Amos Jeffries wrote:
On Wed, 16 Feb 2011 15:20:10 +0200, Eliezer wrote:
im using now squid 3.1.10 and i dont have the store_url_rewrite
option and some of my network users watching youtube videos that i
want to cache.
i had problems with squid2.7stable7 and 3.0.STABLE19
that when a user is listening to stream music on aol\shoutcast
instead of getting into "buffering" cause of a slow connection,
the player will play some buggy noise (really unpleasant ) and like
nothing happened continues the playback for 3 seconds and back the
noise.
ICY protocol abusing HTTP.
http://www.squid-cache.org/Versions/v3/3.1/RELEASENOTES.html#ss2.10
FWIW: 2.7 has a hack to work around the ICY jitter.
acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9]
upgrade_http0.9 deny shoutcast
using squid 3.1.10 solved this problem but i still want the option to
store for sometime youtube videos.
the only way that i was thinking to make it work was to use two squid
versions one is the current 3.1.10 and the other
will be using squid 2.7 just to store youtube videos and maybe pictures.
The jitter is due to ICY players not being nice when the reply headers
are updated according to HTTP/1.1 protocol requirements. Passing it
through *any* HTTP/1.1 compliant proxy which is not aware of ICY and
working around its brokenness will cause the jitter.
Great idea though, using a 2.7 peer dedicated to youtube URLs is a
nice way to get the best of both versions.
Amos