[squid-users] Getting the full file content on a range request, but not on EVERY get ...

Heiler Bemerguy heiler.bemerguy at cinbesa.com.br
Thu May 12 22:34:39 UTC 2016


Hi guys


I just enabled "collapsed_forwarding"  and noticed a lot of "Vary object 
loop!" that wasn't there before..

2016/05/12 19:17:22 kid3| varyEvaluateMatch: Oops. Not a Vary match on 
second attempt, 
'http://ego.globo.com/paparazzo/noticia/2016/05/tulio-maravilha-fala-de-video-intimo-com-mulher-gente-ve-e-deleta.html' 
'accept-encoding="gzip,%20deflate,%20sdch", 
user-agent="Mozilla%2F5.0%20(Windows%20NT%206.1)%20AppleWebKit%2F537.36%20(KHTML,%20like%20Gecko)%20Chrome%2F50.0.2661.102%20Safari%2F537.36"'
2016/05/12 19:17:22 kid3| clientProcessHit: Vary object loop!
2016/05/12 19:17:22 kid3| varyEvaluateMatch: Oops. Not a Vary match on 
second attempt, 'http://ego.globo.com/fonts/typography.css' 
'accept-encoding="gzip,%20deflate,%20sdch", 
user-agent="Mozilla%2F5.0%20(Windows%20NT%206.1)%20AppleWebKit%2F537.36%20(KHTML,%20like%20Gecko)%20Chrome%2F50.0.2661.102%20Safari%2F537.36"'
2016/05/12 19:17:22 kid3| clientProcessHit: Vary object loop!
2016/05/12 19:17:22 kid3| varyEvaluateMatch: Oops. Not a Vary match on 
second attempt, 
'http://ego.globo.com/dynamo/scripts/js/glb.recaptcha.js' 
'accept-encoding="gzip,%20deflate,%20sdch", 
user-agent="Mozilla%2F5.0%20(Windows%20NT%206.1)%20AppleWebKit%2F537.36%20(KHTML,%20like%20Gecko)%20Chrome%2F50.0.2661.102%20Safari%2F537.36"'


I don't know if it's helping with the segmented downloads (that this 
thread is about...) though.


Best Regards,


-- 
Heiler Bemerguy - (91) 98151-4894
Assessor T├ęcnico - CINBESA (91) 3184-1751



Em 12/05/2016 18:21, Alex Rousskov escreveu:
> On 05/12/2016 02:36 PM, Amos Jeffries wrote:
>
>> Have you given collapsed_forwarding a try? Its supposed to prevent all
>> the duplicate requests making all those extra upstream connections unti
>> at least the first one has finished getting the object.
> For the record, collapsed forwarding collapses requests _before_ there
> is any response [header], not after the "first" request got the object
> [body]. Once there is a response [header], the usual caching code path
> kicks in and no collapsing is needed.
>
> Cache hits on that "usual caching code path" read from a "public" cache
> entry. Normally, those public entries are created when Squid receives a
> response [header]. Collapsed forwarding creates that entry before Squids
> gets the response [header], and, hence, before Squid can know for sure
> whether the response is going to be cachable, with all the risks that
> entails.
>
>
> Please do not misinterpret my email as a recommendation to give (or not
> to give) collapsed forwarding a try. I have _not_ analyzed the problems
> discussed on this thread. I just wanted to correct the description
> above. Nothing more.
>
>
> HTH,
>
> Alex.
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160512/99518d52/attachment.html>


More information about the squid-users mailing list