[squid-users] Lots of "Vary object loop!"

[Sebastián Goicochea]

After I sent you my previous email, I continued investigating the 
subject .. I made a change in the source code as follows:

File: /src/http.cc

HttpStateData::haveParsedReplyHeaders()
{
     .
     .
##### THIS IS NEW STUFF ###########
     if (rep->header.has(HDR_VARY)) {
     rep->header.delById(HDR_VARY);
     debugs(11,3, "Vary detected. Hack Cleaning it up");
     }
##### END OF NEW STUFF ###########

#if X_ACCELERATOR_VARY
     if (rep->header.has(HDR_X_ACCELERATOR_VARY)) {
     rep->header.delById(HDR_X_ACCELERATOR_VARY);
     debugs(11,3, "HDR_X_ACCELERATOR_VARY Vary detected. Hack Cleaning 
it up");
     }
#endif
     .
     .


Deleting Vary from the header at this point gives me hits in every 
object I test (that previously didn't hit) .. web browser never receives 
the Vary in the response header.
Now I read your answer and you say that this is a critical validity 
check and that worries me. Taking away the vary altogether at this point 
could lead to the problems that you described? If that is the case .. I 
have to investigate other alternatives.


Thanks,
Sebastian




El 26/08/15 a las 16:11, Amos Jeffries escribió:
> On 27/08/2015 4:11 a.m., Sebastián Goicochea wrote:
>> Hello Amos, thanks for your help. I've disabled our rewriter helper but
>> the errors remain the same. So I think that's not the reason.
> You emptied the cache, or at least altered the cache_dir line to point
> at a new empty cache_dir during the test after disabling the helper?
> anything it might have done to the cache contents is already done to the
> data stored there by the time you disable it.
>
>
>> I've been reading some older mails from the list and a guy named Hussam
>> Al-Tayeb exchanged some interesting mails with you a couple of months
>> ago .. That got me thinking, can I completely disable Vary checking? I
>> know is an http violation and not recommended, but if I could disable it
>> using an ACL for certain sites that are missconfigured and I have the
>> certainty that the content is exactly the same no matter what .. I could
>> get better performance. (It's ok if I have to patch something and
>> recompile squid)
>> If this is not possible, what about "bypassing" content that has the
>> Vary in its response header so squid does not make this 2 lookups only
>> to find that it has to retrieve it from the original server anyway?
>>
> Its not a violation of HTTP. It is a critical internal validity check
> for the cache index itself.
>
> Preventing the contents of say your bank account display page being sent
> to someone else fetching http://google.com/. That kind of critical.
>
> If the Vary meta object is not pointing at the object its supposed to
> be. Then the object it was supposed to be pointing at could be anything
> at all.
>
>
> For your other question. Yes, 3.5 has the store_miss directive now.
> <http://master.squid-cache.org/Doc/config/store_miss/>.
> You can use ACLs in there to check for either the known URLs or the Vary
> header existence on replies and prevent caching of those objects. I'm
> not sure how that will interact with the vary objects in your case but
> none I know of using it has mentioned any issues.
>
> Amos
>
> _______________________________________________
> 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/20150826/58be9445/attachment-0001.html>