|
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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
