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.10Received on Thu Aug 11 2011 - 18:44:42 MDT
This archive was generated by hypermail 2.2.0 : Fri Aug 19 2011 - 12:00:02 MDT