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
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.14
Beta testers wanted for 3.2.0.10
