Unfortunately, none of the suggestions worked .... This is getting really annoying, because application developers insist on saying that the problem is with the Squid, since we tested with somes other proxy servers and not presented the problem ... Don't know what else to do. .. Em 11-08-2011 15:44, Amos Jeffries escreveu: > On 12/08/11 06:22, Rejaine Monteiro wrote: >> >> I agree that the application has serious problems and has already been >> passed it to developers. But I can't do more about it? It is outsourced >> application and they claim that the problem is my proxy and the >> application of them, because all other proxy servers that they tested >> the problem does not occur. For them, the problem is here, with my Squid. >> >> Em 11-08-2011 13:40, Amos Jeffries escreveu: >>> Then those proxies are either not supporting caching of 302 responses >>> or getting different responses to the ones you show here. >> >> This setting below could solve this problem? Because I tried here and >> not relieving effect. >> >> acl broken302 http_status 302 >> cache deny Broken302 >> >> I thank you! >> > > "cache" ACLs are only run on receiving the request, not the reply. So > too early to know. > > refresh_pattern only runs on things already stored and can at most > extend caching times affecting the followup. > > url re-writing only happens on request. again too late, its already > reached the browser. > > location header re-writing is not supported by squid-3. > > header replacement only occurs on delivery to external services. nice > for them, but too late for the object already stored. > > using a deny_info to bounce requires a fixed location to bounce to > different from the original. It appears your app is using the 302 to > bounce to a login page. so is likely to bounce the bounce back to the > jsessionid URL anyway. > But you could try this: > acl site dstdomain ... > deny_info http://...:8080/session.do?app=portal site > http_access deny site > > Amos
