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

[Amos Jeffries]

On 27/08/2015 7:53 a.m., Sebastián Goicochea wrote:
> 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.
> 

I'll have to look into that function when I'm back at the code later to
confirm this. But IIRC that function is acting directly on a freshly
received reply message. You are not removing the validity check, you are
removing Squids ability to see that it is a Vary object at all. So it is
never even cached as one.

The side effect of that is that clients asking for non-gzip can get the
cached gzip copy, etc. but at least its the same URL. So the security
risks are gone. But the user experience is not always good either way.

Amos