Good morning Amos, I would unsuscribe from the mailing list. I have unsuscribed from the forum yet, but i receive mail again. I found the forum very useful, but at the moment i have a different mission in my firm. With reguards Ignazio Raia Invio eseguito dallo smartphone BlackBerry 10. Messaggio originale Da: Amos Jeffries Inviato: martedì 30 giugno 2015 12:46 A: squid-users@xxxxxxxxxxxxxxxxxxxxx Oggetto: Re: TCP_MISS/504 in cache_peer On 30/06/2015 9:42 p.m., Stakres wrote: > Amos, > Yes, similar case here on the 4223. > By reading the case 4223, we can see that part "Non-cacheable objects should > never be added to the digest." from you. > In my squid, there is no restriction, ICP is fully open, squid server > (3.5.5) are compiled with the digest option, so all is done to allow > ICP/digest connection and exchange. > So, why the servers think they got the objects, especially when they are not > cacheable and not cached ? They have *an* object cached for the URL. But not the one the client is requesting from that same URL. Or its got some revalidation requirements attached. Thats what Chudy found. As a result the sibling is unable to supply its cached object as the answer. > > To me, it seems the servers think they have the object but they don't, so > they reply with a 404 translated by a 504 to the squid client because > sibling archi. > I could understand it could be a bug but the squid client should see the 504 > and should request the object from internet, no ? For example; the client wants object no more than 60 seconds old with unique label "ETag:blahblah". But the sibling has a 90 second old object labeled "ETag:oops". It would have to contact the origin to get a new copy, which is forbidden by the sibling relationship Cache-Control:only-if-cached criteria. It's a common problem when using ICP or cache digests which consider only the URL to identify objects. HTCP was created to resolve that problem by considering the whole HTTP header when testing the peer for objects. Though I'm not sure myself if it would resolve the only-if-cached issue. > > At the moment, i use a "retry_on_error on" as a workaround but not sure it's > fixing all 504. > Strange if that is working. The reforwarding happens on 502 and 504 status without any special configuration. That directive just adds 403, 500, 501 and 503 to the list of status that can be retried. > Then, having a dedicated cable between squid servers is not a realistic > solution, my ISP will not see that as a serious solution > > Last point, "no-tproxy rule on parent type cache_peer", it does not work, we > tried that. > We applied that option 1 month ago and the internet sees the squid ip, not > the original ip address, so maybe another bug here... Nod. Without the dedicated link between proxies and TPROXY the parent (or sibling) wont be aware of what IP the original client was using. 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
